SAP S/4HANA Upgrades & Updates: Mastering Zero Downtime Option

2.1 ZDO architecture

Zero Downtime Option is an advanced SUM tool option for performing S/4HANA upgrades and updates, with minimal to near-zero technical downtime

The main advantage of ZDO is that there is no major long-running technical downtime SUM phase as with other upgrade approaches such as standard and nZDM. Disruption is therefore minimal, and the business can continue to run when actual upgrade phases are taking place in the maintenance phase.

The core ZDO architecture is illustrated in Figure 2.1.

Figure 2.1: ZDO architecture

At the end of the SUM pre-processing phase, the system has two instances:

• Main instance (bridge subsystem)—the system remains online for users and continues to process business transactions this is available as an old version. This is an SAP instance of a source (old) version with a newly created shadow HANA database schema.
• SAP shadow instance (upgrade mode)—ABAP repository and schema objects from the target version are created in the SAP shadow instance, where the upgrade activities are executed in parallel as part of maintenance activities, without affecting live operations.

The architecture diagram in Figure 2.1 shows how this dual-system operation enables SAP systems to stay online in the bridge subsystem while SUM executes the technical phases during the maintenance phase, which traditionally required downtime.

2.1.1 ZDO approach—key concepts

In this section, I explain the key concepts associated with the ZDO approach.

Bridge subsystem

The new concept of a bridge subsystem was introduced with ZDO. This is like a clone of the source system (the old release) that runs in parallel to the system being updated during system maintenance.

Once the switch to the bridge subsystem has been completed, the daily production workload continues to run on the newly created ‘shadow’ (SHD) schema, while the remaining update takes place on the main schema. This enables the SUM tool to carry out upgrade tasks during uptime, which in other approaches would typically be performed during downtime.

In summary, the business can continue to run on the bridge subsystem, where SAPHANADBSHD schema accepts all the DML connections from the source system while the original instance and its relevant schema (SAPHANADB) undergo the upgrade.

Pre-processing uptime steps

Once all the SUM pre-requisite tasks are completed prior to the pre-processing phase, all the active users from original instance will be rolled over transparently to the bridge subsystem.

Production/original instance

This is your internal, existing, main instance from which the bridge subsystem is created. All the current production workload will start running on this bridge subsystem.

Shared resources

Internally, all system processes will be shared between the main system and the new bridge subsystem. Actual upgrade maintenance is done in the background.

During the SUM phase, the following tasks will be carried out:

• ‘MAIN_BRISETUP/REQ_USER_ROLLOVER_PREP’
• ‘MAIN_BRTRANS/REQ_USER_ROLLOVER_FINAL’

SUM DB schema connectivity

The Software Update Manager transparently connects users from one database schema to another, without impacting users. After this schema switch, nothing changes with regard to the SAP logon user interface in order to log in to the system.

Internally, SAP will start connecting to the SAPHANADBSHD bridge subsystem schema, instead of the SAPHANADB original schema, to continue business operations in the bridge subsystem.

Parallel execution of update phases

While production business operations continue to run on the source release and on the SHD DB shadow schema, the remaining update phases run in parallel on the main original schema. The Software Update Manager can therefore perform the upgrade during uptime activities in other approaches, this would be done during downtime.

Final cutover phase

At the end of the upgrade, the application server needs to be restarted to activate the new release version. This usually takes two to 20 minutes, depending on how the SAP ASCS and application servers are interconnected.

The SUM tool prompts and performs the restart of the SAP application once the following SUM tool steps have been completed:

• MAIN_POSTPROC/SUBMOD_BRIDGE_POSTPROC/REQ_USER_ROLLBACK_PREP—this phase initiates the restart of the application server.
• MAIN_POSTPROC/SUBMOD_BRIDGE_POSTPROC/REQ_USER_ROLLBACK_FINAL—this marks the completion of the application server start..

There is no further need for the bridge subsystem, and the completion of the above phase indicates the end of the bridge subsystem.

The most important thing to note here is that the HANA database is not restarted during the entire upgrade process.

This solution is new and is not available for standard or nZDM methodologies.

2.1.2 Bridge subsystem—building blocks

An upgrade procedure is started when the system is still running on the old version. Once you are in the pre-processing phase, SUM works internally on two schemas within the one HANA DB instance:

• Bridge schema (SAPABAP1SHD)
• Original schema (on which the actual upgrade will take place (SAPABAP1)).

The ZDO bridge concept is illustrated in Figure 2.2.

Figure 2.2: ZDO bridge concept

The SUM tool creates HANA views for each of the tables in the bridge schema, which will keep looking for any data that has been updated via DML transactions in the original schema. At this point, only one version of the tables (V1) exists, which represents the source release. The original schema continues to be used to access production traffic.

One critical and important milestone phase is the preparation (REQ_USER_ROLLOVER_PREP) and rollover/transition of users to the bridge system. All active jobs/users/work processes are transitioned automatically to the bridge schema, and the bridge subsystem has an active connection.

Once the final phase (REQ_USER_ROLLOVER_FINAL) is completed, and all users are transitioned to the bridge subsystem, the actual/original database system schema is renamed by affixing SHD to its name, which is then used by the bridge subsystem. For example, the SAPABAP1 database schema is renamed SAPABAP1SHD (or, as shown in the image, SAPHANADBSHD).

The original system, in which the upgrade is performed, is still connected to the original database schema (SAPABAP1 in the example).

Although the actual upgrade is carried out on the new version (V2), V1 will keep referencing the data from the old/source release and the production system will continue to be used on the bridge subsystem without impacting the business.

In addition, if no table structure adjustment is needed during the upgrade, no new/extra V2 table is created. Refer to the example shown in Figure 2.3, for Tab 2, V1=V2. The generated view (View 2) still points to this table.

Figure 2.3: ZDO bridge—deep dive

2.1.3 Shadow instance enhancements

The shadow instance is one of the most critical architectural components in a ZDO upgrade. Standard or nZDM upgrades also use a shadow instance, but the way it is leveraged in ZDO is significantly different. With ZDO, the production system remains online throughout the uptime process, in the bridge subsystem, where it uses shadow schema on the HANA database.

Let’s look at some of the main enhancements to the shadow system with ZDO.

Support for bridge uptime architecture

The shadow instance handles all table activations and DDIC (data dictionary) changes without touching the live tables. These updated structures are ready to take over once the bridge subsystem is no longer in use.

No impact on the live system

If any errors occur in the shadow system, they do not interrupt business operations. SUM has the capability of safely stopping or rolling back the shadow creation process.

Trigger-based synchronization

Trigger-based synchronization enables you to capture changes made during uptime, via CRR technology delta logs are applied, so structural changes are always in sync. The final cutover period therefore needs minimal downtime, because both the shadow and original instances are always synchronized.

Improved handling of large tables

As the business continues to run using the bridge subsystem, many large tables are cloned and processed in the shadow system. ZDO-specific enhancements support efficient clone creation, trigger-based updates, and faster comparison and activation.

Enhanced parallelization and CPU (Central Processing Unit) utilization

ZDO-specific SUM improvements enable better parallel processing in the shadow instance:

• Faster table conversions
• Faster XPRAs/after-import methods
• Efficient use of multiple cores during shadow build

This is why SUM host sizing is so important for ZDO.

Smooth switchover to upgraded environment

Shadow instance enhancements to bridge switchover ensure that cutover is faster, there are no inconsistencies, and user transition is completely transparent, without any major changes.

As highlighted in Figure 2.4, the ZDO approach enables nearly all upgrade activities to be performed during uptime, thereby isolating heavy technical tasks, improving activation logic, supporting bridge mode synchronization, and drastically reducing downtime during final cutover.

Figure 2.4: Shadow system enhancements