This article helps to understand the parallelism import mechanisms and its working in SUM and SPAM tools respectively.
Here, “parallelism” means:
1) the import of more than one package or more than one object of a package at the same time by the transport tools (tp and R3trans);
2) the execution of more than one background jobs on the batch phases (both dialog and batch);
3) the execution of more than one SQL process on the database level;
4) the execution of more than one R3load processes on the EU_IMPORT phase (loading data from DVDs in release upgrades) and on the migration of data in DMO scenarios (data migration option);
5) the execution of more than one phase at same time, during the UPTIME portion of the upgrade.
Explanation of parallelism for SUM in details:
When executing the Software Update Manager tool, we are prompted to enter numerical values for several parameters in phase INITSUBST:
–> The first parameter, ABAP PROCESSES, sets up the number of processes used in job phases. This influences all job-run phases, including long runtime ones like DBCLONE (in update scenarios), ACT_UPG and PARDIST in uptime, and XPRAs in downtime.
During uptime, we cannot set up more batch processes than the system has available (seen in SM50 or RZ04), on your source system. If we surpass the number of batch jobs available, the batch system will serialize them, resulting in no performance gain.
For DBCLONE phase there is technical limitation of 10 parallel processes at the most, so a higher number will not help. For ACT_UPG, the limit is 6 parallel processes, but this phase was benefited from code optimization in SUM SP12, improving dramatically its runtime. For PARDIST phases, 10 processes is the technical limit also.
**Note** the parameter rdisp/wp_no_btc (Number of work processes of type batch – background processing) holds back the number of parallel processes! Please ensure we have at least an equal number of background processes available, otherwise parallelism will not be obtained. We might also notice the following warning on the logs:
“2WETQ399 Cannot run 10 batch processes, system has only 1!”
–> The second parameter, SQL PROCESSES, defines the number of parallel SQL statements to be run on the database at the same time. This setting is specially useful for the DDL-phases (data definition language), like MVNTAB and PARCONV, where the “create table”, “alter table”, “create index” and other commands take place. Also the phases that create aliases/synonyms of the shadow system use this parameter (SCEXEC_GRANT + SCEXEC_ALIAS), but to a less extend. The recommended value is the total number of physical CPUs (using the same logic of R3TRANS PROCESSES below).
–> The third parameter, R3TRANS PROCESSES, is used for tp and R3trans transport tools in parallel, on the phases where import of support packages take place (DDIC_UPG, SHADOW_IMPORT* and TABIM_UPG). This type of import can be performed by the transport tools since SAP_BASIS release 700, according SAP Note 1127194 “R3trans import with parallel processes”. This is the setting that brings the most benefits in terms of overall performance in upgrades because of the number and size of the packages imported at different stages. The recommended value is the same number of physical CPUs available on the server, to follow the “1 parallel import process per CPU”. we can view the number of CPUs available in transaction ST06, on “CPU count”. If your CPU is a multi-core one, SAP System will consider them as a physical, available CPU. For example: if we have 4 quad-core CPUs, they are seen by SAP System as 16 CPUs in ST06. On this case, we can enter ’16’ for both UPTIME and DOWNTIME R3TRANS PROCESSES fields (remember that ordinary transport requests import might still take place during uptime, and they share the same tp/R3trans resources. So avoid importing requests during upgrades).
During such phases, the number of parallel processes on the OS will vary greatly, due to the many packages/objects reading and writing into the database.
Depending of the upgrade strategy, the phases can be run during the uptime or in downtime portion:
Please take into consideration the database parallelism information below before setting up a definitive number for R3TRANS PROCESSES, which explain in detail later.
–> The fourth parameter, R3LOAD PROCESSES, tells the upgrade tool how many R3load processes will be triggered during phases EU_IMPORT* (in system releases upgrade) and in DMO (data migration option) scenarios, to move the data from the old database into the new HANA one. Since R3load utilizes small CPU processing, we can safely enter a significant number for this parameter: 3 to 5 times the number of CPUs, being “5” the theoretical top limit.
In SUM guide it also explain about parallelism. Specially in chapter A.3.2: Configuring Parallel Processes During the Runtime, where it instructs how to modify the number of processes after they were entered in phase INITSUBST.
This procedure is also described in KBA #1904239: SUM options to change parameters entered in INITPUT and INITSUBST phases, and can be used in case we need to modify the number of processes before starting the phase we want to have the changes in effect.
Explanation of parallelism for SPAM & SAINT in details:
Parallelism can be obtained on the ABAP tools Support Package Manager and Add-On Installation tool. Please find below a comparison between the tools:
In some occasions parallelism might not work in SPAM and SAINT, even if the corresponding settings are correctly configured and the transport tools are up-to-date. On such cases please check of the ACC_IMPORT parameter is set in the transport profile. This parameter deactivates the parallelism for SPAM/SAINT imports!
The parameter ACC_IMPORT is useful for large number of small transports. In this mode, tp and R3trans process one import after another, using inter process communication to avoid starting/stopping of processes. For large transports (like Support Packages), this parameter is counterproductive, because it forbids parallelism. Please refer to note #1223360 for more information about it.
Additional Database-specific information:
Each database has its own internal parallel mechanics, which work apart from the SAP Upgrade tools. We have to consider the resources usage on the database side alongside the upgrade tool parallel operations to avoid exhausting the Database, specially in case we run the database on the same server of the Primary Application Server (PAS, the old Central Instance Server) or can check with Database Team.
1) MSSQL: please refer to the below article, we have to set up the MaxDOP setting accordingly, paying attention to not go overboard.
https://docs.microsoft.com/en-us/archive/blogs/saponsqlserver/max-degree-of-parallelism-maxdop
2) Oracle: there are no special instructions other than having the parameters correctly configured according to note #1888485 (Oracle 12), #1431798 (Oracle 11) and #724716 (Oracle 10). An Oracle parallelism FAQ do exist in SAP note #651060.
3) Sybase (ASE): Sybase’s Adaptive Server Enterprise has its own Upgrade parameters, available as a PDF attachment in note #1680803. The section “IMPORT” is of particular interest since it deals with the DDL statements on the database (page 28. Also page 49, on the section “Reconfigure Engines and Parallel Processing”). The normal operations parameters can be found in note #1539124. Also please refer to Sybase’s online DB manual here, specially to chapter 7 “Parallel Query Processing”.
4) HANA: HANA has a parallelism mechanism designed by concept, so there is not special adjustments for Upgrades. This document provides a good higher level overview of its mechanics. Anyway we can tweak parallel workers as per notes #2100040 and #2000003 for daily use.
5) MaxDB: no special instructions related directly to upgrade. As a general performance recommendation, please refer to the MaxDB’s Database Parameter page (about parameter MaxUserTasks, MaxCPUs and MaxUserTasks) and to the following notes:
6) DB2 for i: please refer to the white paper which is available on IBM’s tech docs library: IBM Tech docs White Paper: SAP Software Update Manager: Behaviors and Insights. It contains optimizations and platform specific advises for different stages of the upgrade. This document has been completely overworked to cover aspects of SAP’s current standard upgrade tool SUM on platform IBM i.
Tips & tricks:
In order to avoid the error message “===> HALT: creation of child process for parallel import failed. Please contact the SAP support.” during the parallel import, make sure the UNIX/LINUX system is set as unlimited and the parameter MAXUPROC (Maximum users processes) is large enough, it is normal during the parallelism the user <SID>adm starts a very high number of processes;
Before starting the upgrade, make sure the database is optimized, updating statistics and parameters. In additional use the latest version of TP and R3trans.
Avoid to use NFS in the upgrade directory, it should be a local file system, due the high I/O volume.