Way to increase "MAXIMUM UPTIME PROCESSES" during preprocessing phase

Question

Hi All,
It has always been frustrated when your ACT_UPG, SHADOW_IMPORT_INC phases are running very slow due to low number of MAX UPTIME PROCESSES enter earlier.
I've been looking for a method to increase MAX UPTIME PROCESSES during upgrade, or shadow instance creation, but to no avail and guru here said there's no way to amend the Uptime Processes after you input the value during the preparation phase, but just to wait until it finish.
However, i found out this can be done by changing the value for parameter mainimp_proc in *.TPP files (located under EHPI\abap\bin). eg of *.TPP files to be changed are based on the *.ECO located under EHPI\abap\tmp)
For instance:
youu2019ll see below command in TPAPP.ECO file:
EXECUTING D:\usr\sap\EHPI\abap\exe\tp.exe pf=D:\usr\sap\EHPI\abap\bin\SHDUPGIMP1.TPP
Therefore, you can increase the number of UPTIME processes by changing the value mainimp_proc in SHDUPGIMP1.TPP
In order to change this, first, you need to kill the R3trans processes, and SAPehpi will prompt you the error message. take this opportunity to change the parameter. Make a backup before you change any files.
To maintain consistency, i think is good to amend parameter mainimp_proc in every *.TPP based on the time it created when you launch the EHPI. Because, SAPEHPI will generated the value you enter into *.TPP file base on the global template. Also, check on every *.ECO file in /tmp for each phase to determine what *.TPP file is being read.
example of .TPP files:
SHDUPGIMP1.TPP, SHADOW.TPP, DEFAULT.TPP, TOOLIMPM.TPP, TOOLIMPI.TPP, and etc
For your information, it is not recommend to change the processes during the upgrade and you should bear your own responsibility. The purpose of this post is just for sharing.
For my situation, my colleague has insert value "2" for MAX UPTIME PROCESSES and it's veryslow due to only 2 R3trans is running and the clock is ticking for us. I change the parameter to "6" after some analysis done how EHP read the value. The good news is i can see 6 R3trans are running and 6 Support Packages are importing in /EHPI/abap/tmp.
Time it takes to complete had shortened tremendously and upgrade completed without any error.
Please provide any feedback on how it works if youu2019ve tried it or going to try it in future.
Thanks,
Nicholas.

Answer 1

> Please provide any feedback on how it works if youu2019ve tried it or going to try it in future.
Just to throw in my EUR 0.02:
In most cases you do an upgrade not only one on a production system but also before on a test system - or at best - on a copy of the production.
At the end of the upgrade you get an UPGEVAL.XML file that lists the runtime of the various phases and also the configuration.
For such huge upgrades ('real' upgrades or e. g. EHP4) we do this upgrade several times with copies of the production (3+ TB database) and try to optimize the runtime for us plus avoiding most of the errors during activation and upgrade phases. For our EHP4 project I did a total of 6 upgrades in a copy of the production to find the optimum number of processes. This implies however, that resources are available (in sense of time and hardware) but we found out from the past, that this invest is of much more use than having a trembling administrator on a sunday evening sitting there and hoping that there'll be no restore of the database necessary.
With todays database and/or storage technologies (snaphots/clones) it's no more a big administrative task to copy a system and reset it after the upgrade and start over if it was too slow.
Out of my experience I would say, that I'd set the parameters always as high as the number of CPUs you have on the server executing the upgrade process, it's very rare that the machine comes to its CPU limit with nowadays CPU power, even if there's the production running.
Markus