Discovering Zero Downtime Option for SAP S/4HANA


After completing this lesson, you will be able to:

  • Explain the Concept of the Zero Downtime Option Approach

Basic Concept of Zero Downtime Option Approach

This section provides an overview and key facts on the Zero Downtime Option (ZDO) of Software Update Manager (SUM).

Zero Downtime Option at a Glance

Planned downtimes for system maintenance events like release upgrades and feature or support package stack updates can be expensive. The ideal solution would be to run an upgrade or update without having a technical downtime. This can be achieved by using the Zero Downtime Option of SUM.

  • Zero Downtime Option is an option of Software Update Manager to reduce the technical downtime.
  • With ZDO, all phases are executed during uptime processing.
  • SUM phases that are typically causing long technical downtimes:

    i. Table conversion and DDL execution - phase: PARCONV_UPG

    ii. Main import - phase: TABIM_UPG

    iii. XPRAs, XCLAs, and AIM execution - phase: XPRAS_AIMMRG

  • In addition, the business downtime can be significantly reduced by using ZDO.
  • The approach requires higher effort in terms of functional validation as well as project planning.
  • Like for standard updates and upgrades of SAP S/4HANA, SUM 2.0 is used.

The ultimate goal of ZDO is to provide a solution to apply release upgrades, feature or support package stack updates for SAP S/4HANA without technical downtime. The basic steps of the ZDO procedure are as follows:

  • Business users work on the original system on release 1 that represents the source release.
  • Meanwhile, the uptime processing of SUM has been started.
  • At the end of uptime processing, SUM will rollover the business users to the so-called bridge subsystem.
  • The bridge subsystem still represents the source release as the target release is yet to be finalized by SUM.
  • Transitioning the users to the bridge subsystem happens in a controlled manner by the administrator.
  • The business users can continue with their work since the transition to bridge happens seamless.
  • While the business continuous to work, the target release is finalized in parallel by SUM.
  • During the maintenance procedure, transactional consistency is ensured.
  • Both releases, source and target, are stored in the same database but the access happens using different database schemas.
  • Separating the releases into different database schemas ensures the encapsulation and isolation of both releases.
  • At the end of the maintenance event, the target release needs to be activated.
  • The cut-over and activation of the target release includes the following steps:

    i. Ramp-down release 1 which typically includes tasks like log off users, lock users, de-schedule batch jobs, cleanup queues, and clean erroneous update processes.

    ii. Parallelized restart of all application servers by SUM. The database is not restarted.

    iii. Ramp-up of release 2 that typically includes tasks like import of transports, functional validation, unlock users, re-scheduled batch jobs.

  • After the restart and ramp-up of the system, users will work on release 2 that represents the target release.

Key Facts About Zero Downtime Option

  1. ZDO comes along with SUM that is the standard tool for software maintenance. There is no additional license needed and no separate tool required.
  2. The database footprint is rather small since not the entire database is cloned. Instead, only selective tables are cloned. The cloned tables are determined based on the changes to be performed with the maintenance event.
  3. The technical downtime goes down to a single restart of the application servers. The database, however, is not restarted. Usually, the restart takes approximately 5 to 15 minutes depending on the number of application servers.

Naming Conventions and Glossary

This section describes terms and phrases used in this training.

Naming Conventions and Glossary

Bridge subsystemThe state of the system when all existing application servers are reconnected to the bridge database schema. From a technical perspective, the bridge database schema reuses the shadow database schema.
Original systemThe state of the system which uses the default database schema like SAPHANADB.
Shadow systemThe shadow system is used to prepare the repository and dictionary objects of the target release in the shadow database schema.
Upgrade subsystemFinalization of the target release repository. The upgrade subsystem operates on the original database schema.
SAPupExecutable called internally by SUM.
SUMShort for: Software Update Manager
UpdateThe term update is used as a collective term for all the software logistics processes that you can perform using the Software Update Manager (such as performing release upgrades or updating a system with feature or support package stacks).
ZDOZero Downtime Option. A procedure to minimize the technical downtime during the maintenance event.

Log in to track your progress & complete quizzes