Discovering Zero Downtime Option for SAP S/4HANA

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 Software Update Manager.

• Zero Downtime Option is an option of Software Update Manager to reduce the technical downtime.
• With ZDO, all phases are executed during uptime processing.
• Software Update Manager phases that typically cause long technical downtimes:
  1. Table conversion and DDL execution - phase: PARCONV_UPG
  2. Main import - phase: TABIM_UPG
  3. 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®, Software Update Manager 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 Software Update Manager has been started.
• At the end of uptime processing, Software Update Manager 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 Software Update Manager.
• 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 seamlessly.
• While the business continuous to work, the target release is finalized in parallel by Software Update Manager.
• 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:
  1. 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.
  2. Parallelized restart of all application servers by Software Update Manager. The database is not restarted.
  3. Ramp-up of release 2, which 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, which represents the target release.

1. ZDO comes along with Software Update Manager, which 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 the entire database is not 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.