Fast hardware is key to speeding up the update. With faster hardware, the overall runtime decreases and, therefore, the downtime as well.

Some phases benefit from a faster CPU and additional memory. Other phases require fast disk I/O.

• CPU

  Several phases run parallel processes. However, since the number of parallel processes is not larger than eight, more CPUs may thus not be exploited fully. Four CPUs with 800 MHz are faster than eight CPUs with 400 MHz, for example.

• RAM

  Additional memory for the database and the SAP kernel can improve speed, especially for phases that use the SAP system, such as the activation phase or the XPRAS phase.

• Disk I/O

  During the main import phases (EU_IMPORT (release upgrade only), SHADOW_IMPORT, TABIM), a fast disk I/O is the key to reducing the upgrade runtime.

You need to be able to restore the update to the point when downtime began. You can do this using your usual backup and archiving model. You also need to make a backup of your database after the update has finished.

You can reduce the downtime significantly if you use a fast backup mechanism, such as a RAID-based mechanism or a hardware-based mirror mechanism.

You can configure the update by modifying the number of processes used:

• Number of background processes

  This is the key parameter for running ABAP reports in parallel. Increasing this parameter speeds up phases like PARDIST_ORIG, PARCONV_UPG, and XPRAS_UPG. A value larger than 8 does not usually decrease the runtime.

• Number of R3trans processes

  This parameter affects the number of R3trans processes that tp starts during phases SHADOW_IMPORT and TABIM. A value larger than 8 does not usually decrease the runtime.

Do not increase these parameters to values much larger than the number of CPUs in your system.

The number of clients has a significant influence on the runtime. During phases SHADOW_IMPORT and TABIM, the data import for some client-specific tables needs to be cascaded into the different clients. The import time therefore increases with the number of clients.

The duration of the XPRA phase, especially the duration of the after-import methods, also depends on the number of clients.

If you no longer need certain clients, you should delete them before you start the Software Update Manager because the free space calculation depends on the number of clients.

In some cases, it is useful to archive some of the content of large tables. If tables are converted during the update, the conversion time depends on the size of the table. If you can decrease the size of a table that needs to be converted, the downtime is reduced. The tables converted during the update are summarized in the reports of the Using the SUM Analysis Feature utility.

The duration of the phase XPRAS_UPG also depends on the size of large tables.

If you have modified some tables in the source release, you may need to convert them if you choose to return to the SAP standard.

This may mean that you need to remove some fields or reduce a field length. You may want to consider keeping your modification to avoid such a conversion.

During a test update, errors might occur. These errors increase the runtime and downtime of the update significantly.

During the tests, find out, if necessary with the help of SAP Support, how to prepare the SAP system so that these errors do not occur again. For example, if the process fails in phase PARCONV_UPG because the tablespaces or containers are too small, increase the free space by the amount of space you need to run the phase.