Analyzing the Downtime of the Software Update Manager Procedure

Objective

After completing this lesson, you will be able to explain the influencing factors of the downtime of the Software Update Manager procedure.

Downtime of the Software Update Manager Procedure

Technical Downtime

The beginning and ending of downtime is not a 'click' but can be a complex process involving, for example, stopping the production line with all its implications.

Both can take hours of time. Therefore, these are called 'ramp down' and 'ramp up', rather than 'stop' and 'start'.

This figure shows a more schematic view of the procedure.

The highest potential lays in:

  • Speeding up the delta transports and manual tasks.

  • Speeding up business validation test, for example, using tools like eCATT.

Influencing Factors for Downtime

Runtime is the total duration of the time controlled by the Software Update Manager including preparation and uptime activities.

Runtime and downtime depend on the following:

  • Hardware and operating system: The whole installation runtime depends on the hardware that you use.

  • Hard disk configuration: input/output throughput, backup speed.

  • Database: size of tables, database configuration, parameter tuning.

  • Number of modifications.

  • Number of data structure conversions: phase PARCONV_UPG; depends on start/target releases; bigger leaps mean more data conversions.

  • Productive applications: more productive applications mean more data conversions.

  • Number of clients: client cascade in phase TABIM_UPG.

  • Number of installed languages: more data import.

  • Amount of data to be converted.

A test Software Update Manager run on a production system mirror (sandbox system) and thorough analysis of the installation log files can highlight many possibilities for effective manual tuning activities early in the project.

Overview of Factors affecting Runtime and Downtime
Decoupling Conversion and Migration

You can perform the SAP S/4HANA Conversion, including DMO, in one step. But the needed downtime window may be too long.

If the start release is SAP_BASIS 740 or above, you can split the SAP S/4HANA Conversion in two projects:

  • First, do the database migration to SAP HDB.

  • Second, perform the SAP S/4HANA Conversion without DMO.

Note

Working with an SAP HDB is only possible if the source release is at least SAP_BASIS 740.

Additional topics are:

  • SAP application server configuration.

  • SAP HANA database configuration.

  • Observation and management of available system resources.

The next two slides show additional downtime optimization techniques that can be used under certain circumstances:

Downtime Reduction Techniques (1)

Near-Zero Downtime Maintenance (nZDM) and Downtime Optimized Data Conversion are discussed in detail in the following lessons of this unit.

Downtime Reduction Techniques (2)