Upgrade Guide | PUBLIC

Software Update Manager 2.0 SP21

Document Version: 1.0 – 2024-09-27

Zero Downtime Option for SAP S/4HANA

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

THE BEST RUN

Content

1 Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1 About This Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Required SAP Notes and Further Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
1.3 New Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 The ZDO Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Downtime Optimization Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Technical Details of the Zero Downtime Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Specific Phases for ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

3 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Project Planning Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Test Cycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Exemplary High-Level Project Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Additional Steps for ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Estimation of the Right Time for Rollover and Rollback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Impact Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Impact Analysis at a Glance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Exporting Table Statistics to the Productive System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Impact Analysis Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Applying Best Practice for Impact Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Restrictions During the Runtime of the Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Hardware Requirements Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 High-Availability Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Add-On Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Preliminary Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Handling UPL Data Collection Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 SAP Business Warehouse Extractor Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Silent Data Migration Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
4.8 Handling of Database Triggers (Including SLT Replication). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9 SLT Database Trigger Handling in ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Case Scenario 3: Subscription-Based Change Data Capture Mechanism. . . . . . . . . . . . . . . . . . .42
Case Scenario 4: Legacy Change Data Capture Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 SAP HANA Scale-Out Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Zero Downtime Option for SAP S/4HANA

2 PUBLIC Content
4.11 Usage of Custom Database Schemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.12 Backing Up Table Content in the SAP HANA Repository 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
4.13 Migration of Native SAP HANA Database Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.14 Backup Strategy for ZDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Running the Software Update Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 Roadmap Steps with ZDO Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Get Roadmap: Enabling ZDO During the Initial Dialogs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Preprocessing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Postprocessing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Special Features for ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Resetting the ZDO Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Restoring Table Content in the SAP HANA Repository 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Final Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Bridge and Update Subsystems During the Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Transition of Users to Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Database Reconnect Transition Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Locks on the Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Handling Problems with Specific Table Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Follow-Up Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1 General Troubleshooting Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Known Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Zero Downtime Option for SAP S/4HANA

Content PUBLIC 3
Document History

Document: Zero Downtime Option of SUM 2.0 SP 21 for SAP S/4HANA

The following table provides an overview of the most important document changes.

 Caution

Before you start implementation, make sure that you have the latest version of this document. You can
find the latest version on the SAP Support Portal athttps://help.sap.com/docs/SLTOOLSET. Choose tab
System Maintenance, then the scenario Zero Downtime Option (ZDO) for SAP S/4HANA using SUM 2.0.

Version Date Description

1.0 2024-10-07 Initial version

Zero Downtime Option for SAP S/4HANA

4 PUBLIC Document History
1 Before You Start

This part of the document contains information about the basic aspects of this ZDO guide.

1. About This Document [page 5]

2. Naming Conventions [page 6]
3. Required SAP Notes and Further Documentation [page 5]
4. New Features [page 6]

1.1 About This Document

This document gives you an overview of the upgrade and update procedure of SAP S/4HANA with the Software
Update Manager (SUM) tool using its Zero Downtime Option (ZDO).

To reduce the technical downtime of your SAP S/4HANA system to the minimum, SAP introduced a procedure
that allows users to continue using the business functions of the system during the upgrade or update
activities. This feature is provided with the Zero Downtime Option (ZDO) feature of the Software Update
Manager (SUM) tool.

This document explains the high-level concept and the principles of ZDO, giving you a transparency you
need to understand how ZDO is organized and functioning. Going further you receive an initial information on
planning, preparation, and follow-up activities as well as information about using SUM with ZDO.

The focus is on the special features of ZDO, assuming you´re familiar with SAP upgrade and update procedure
using SUM tool. The information in this document is intended primarily for SAP system administrators with
operating system, database, and SAP NetWeaver Application Server knowledge, and would be interesting and
useful for the functional experts as well as project managers.

The document

• provides you with information to consider before and during the upgrade and update procedure using SUM
with ZDO, and what you can do in case you encounter errors
• describes specifics, when you want to upgrade or update your existing SAP systems based on SAP
NetWeaver Application Server for ABAP using ZDO

1.2 Required SAP Notes and Further Documentation

In addition to this document, you need other information such as the current central SUM note or the SUM
guide for SAP ABAP systems.

The SUM guide describes how to update SAP systems based on SAP NetWeaver using the Software Update
Manager (SUM). It includes planning, preparation and follow-up activities, information about using SUM, and
troubleshooting information.

Zero Downtime Option for SAP S/4HANA

Before You Start PUBLIC 5
The latest version of this document as well as the central SUM note are available on the SAP Support Portal at:
https://support.sap.com/sltoolset → tab "System Maintenance" System Maintenance Scenarios
Software Update/Upgrade using SUM .

Furthermore, check the following SAP Notes on ZDO before you start:

SAP Note Title

2707731 Prerequisites and Restrictions of Zero Downtime Option of

SUM for SAP S/4HANA

These SAP Notes have more information about the

• supported products and releases

• required database versions
• restrictions on the application side

1.3 New Features

The following table lists significant new features and improvements of the Zero Downtime Option of SUM 2.0.
The table also indicates the SUM version in which the new or improved features were introduced.

Feature Description Availability

Handling Problems with Specific A new chapter has been added that deals with prob- SUM 2.0 SP 19
Table Changes lems caused by changes to tables during a system
update or upgrade. For more information, see Han-
dling Problems with Specific Table Changes [page
63].

SLT Replication during a ZDOP- The SLT chapter has been compeletely revised de- SUM 2.0 SP 21
procedure scibing now the different options of the SLT Replica-
tion during a ZDO procedure. For more information,
see sectionSLT Database Trigger Handling in ZDO
[page 39]

1.4 Naming Conventions

This section deals with the most important naming conventions used in this document.

For more naming conventions, see the SUM Guide mentioned in Required SAP Notes and Further
Documentation [page 5].

Zero Downtime Option for SAP S/4HANA

6 PUBLIC Before You Start
Term Description

bridge subsystem The state of the customer system when all existing application serv-
ers are reconnected to the bridge database schema. From a tech-
nical perspective, the bridge database schema reuses the shadow
database schema.

customer buffer A file that contains the list of customer transports.

FDCT Short for: fast data copy transfer. Refers to copying content of
changed tables to a target version table.

original system A customer system as combination of an SAP ABAP system and a

database schema (including all related objects, that is, repository
and application tables) for which the maintenance event is planned.

SAPup An executable that is called internally by SUM.

shadow system and shadow database schema The shadow system is used to prepare the repository and the
dictionary objects of the target release in the shadow database
schema.

SLT and CDC replication SLT is short for: SAP landscape transformation

CDC is short for: change data capturing

SLT is an extraction, transformation, and loading (ELT) tool that

allows you to load and replicate data in real time, or to schedule data
from a source system and a non-source system into the SAP HANA
database.

SUM Short for: Software Update Manager

SUM directory Directory that is created when the SUM archive is unpacked on the
host where the tool is initially started. During the unpacking, data
and programs are copied to this directory.

The recommended standard path of the SUM directory is: usr

sap <SID> SUM

target system Final system state running on the target release. The system is
connected again to the original database schema.

update A collective term for all the software logistics processes that you can
perform using SUM (such as performing release upgrades, installing
enhancement packages, or updating a system with support package
stacks).

In this document, the term is used in the context of

• release upgrades
• application of feature package stacks
• application of support package stacks

using SUM.

upgrade subsystem Finalization of the repository of target release. The upgrade subsys-
tem operates on the original database schema.

Zero Downtime Option for SAP S/4HANA

Before You Start PUBLIC 7
Term Description

UPL Short for: usage and procedure logging. It is used to log all called
and executed ABAP units such as programs, function modules,
classes, methods, and subroutines.

V1 Stands for version 1 and represents the source release.

V2 Stands for version 2 and represents the target release.

ZDO Short for: Zero Downtime Option. A procedure to minimize the tech-
nical downtime during the maintenance event.

Zero Downtime Option for SAP S/4HANA

8 PUBLIC Before You Start
2 Introduction

This part of the document contains information about the basic concept and the technical details of the ZDO of
SUM.

1. The ZDO Concept [page 9]

2. Downtime Optimization Approaches [page 11]
3. Technical Details of the Zero Downtime Option [page 11]
4. Specific Phases for ZDO [page 14]

2.1 The ZDO Concept

This section describes the idea behind the Zero Downtime Option (ZDO) of the Software Update Manager
(SUM).

A technical system downtime during an update can be expensive. For this reason, the ideal solution would
be to run an update without having a technical system downtime. With the ZDO of SUM, updates of ABAP
applications can be run without a technical downtime and with a minimized business downtime.

The idea behind ZDO is to have a bridge-subsystem in parallel with the production system. During the update
on the production system, users can continue their work on the bridge-subsystem. The bridge-subsystem
reflects the source release and contains all data of the production system that users need to continue their
work.

All business transactions of the applications that are enabled for ZDO are fully available during the update.
Applications that aren't fully available during the bridge runtime are listed accordingly in SAP Note 2707731 .
Users can continue, for example, working with transactions, scheduling and running batch jobs, and running
print requests.

During the update, the network connections between systems are preserved.

The ZDO approach is beneficial for the following maintenance events:

• Applying support package stacks

• Applying feature packages
• Customer releases
• System release upgrades

Zero Downtime Option for SAP S/4HANA

Introduction PUBLIC 9
There are three facts about the Zero Downtime Option:

1. ZDO comes along with SUM that is the standard tool for software maintenance. There's 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 clone tables are determined based on the changes to be performed during the
maintenance event.
3. The technical downtime goes down to a single restart of the application servers. The database, however,
isn't restarted. Usually, the restart takes approximately 5 to 15 minutes dependent on the number of
application servers.

For more information, see also the blog Leveraging Zero Downtime Option of SUM for SAP S/4HANA Support
Package Stack updates in the SAP Community.

Zero Downtime Option for SAP S/4HANA

10 PUBLIC Introduction
2.2 Downtime Optimization Approaches

The Software Update Manager supports downtime-optimized approaches for some scenarios for updating SAP
S/4HANA.

In the past years, the approaches to minimize downtime have evolved significantly. Among the approaches
shipped along with Software Update Manager 2.0, there are three main approaches for applying release
upgrades, support package stacks, and feature package stacks:

Both, the standard approach and the near-Zero Downtime Maintenance (nZDM) include major improvements
for minimizing the technical downtime. However, the technical downtime cannot be reduced with the standard
approach and also not with nZDM. This can be achieved with the Zero Downtime Option (ZDO) of SUM as the
next level of downtime-optimization.

Note, however, that the more you want to optimize the downtime, the more effort you have in the project.
The effort includes both the project planning effort and the testing effort, which is higher for zero downtime
updates.

You can get an overview about the different approaches and scenarios on the SAP Support Portal at https://
support.sap.com/en/tools/software-logistics-tools/software-update-manager.html#section .

2.3 Technical Details of the Zero Downtime Option

This section deals with the Zero Downtime Option (ZDO) from a technical point of view.

The basic principle of the ZDO is to update an SAP system while production is running in parallel. When
updating with ZDO, the SAP system runs productively on the old release while the update process is performed
at the same time. In this way, the update has no technical downtime.

Zero Downtime Option for SAP S/4HANA

Introduction PUBLIC 11
The following figure illustrates how the technical downtime is already reduced when using the nZDM approach.
With the ZDO approach, the technical downtime can be eliminated and replaced by the uptime on the bridge.

The General Solution Approach

The bridge subsystem is a part of the existing system that runs in parallel to the update subsystem during
system maintenance. In the standard approach and the nZDM approach, all users are logged off from the
system at a certain point in time, and the technical downtime starts. With the ZDO approach, all users are
transferred transparently and in the background to the bridge subsystem. The Software Update Manager
connects the users from one database schema to another database schema.

The following picture shows the basic steps of the ZDO procedure:

1. Business users work with release 1 while the update is running in the uptime.
2. Business users are smoothly transferred and reconnected to the bridge subsystem without any
interruption.
3. While productive business operations continue on the source release, the remaining update phases run in
parallel on the subsystem that is being updated. In this way, the Software Update Manager can perform
during uptime activities that are performed in other approaches during downtime.
4. At the end of the update, the application server must be restarted to activate the new release version,
which usually takes between 5 and 15 minutes. The database is not restarted.

Zero Downtime Option for SAP S/4HANA

12 PUBLIC Introduction
 Afterwards, the system is on the new release 2.

The Bridge Concept

1. At the beginning of the ZDO procedure, the upgrade system is running on the original version. During an
update with ZDO, SUM works on a single database with two schemas: The bridge schema (for example in
the following figure SAPABAP1SHD) and the original schema (SAPABAP1 in this example).

2. The Software Update Manager generates for each SAP-specific or customer-specific table a view in the
bridge schema, which then refers to the original tables. At this point in time, only one version of the tables
(V1) exists, which represents the source release. The original schema continues to be used productively.
3. When the rollover to the bridge subsystem is initiated in phase REQ_USER_ROLLOVER_PREP (see also
Transition of Users to Bridge Subsystem [page 61]), all work processes are automatically reconnected to
the bridge schema in phase BRIDGE_RECONNECT (see also Database Reconnect Transition Method [page
62]).
After all users have been transferred to the bridge subsystem, the default database schema of the
production system is renamed by appending SHD to its name. For example, the SAPABAP1 database
schema is renamed to SAPABAP1SHD.
The upgrade subsystem with which the upgrade is performed, is still connected with the original database
schema (SAPABAP1 in the example).
4. While the upgrade is being performed on the target release tables (V2 tables), the generated views (view
1 in the example illustration) continue to point to the source release tables (tab1 V1 in the example). As a
result, the productive use can continue on the bridge subsystem.
If no adjustment of the table structure is required during the upgrade, no additional V2 table is created (in
the example, tab 2 V1=V2), and the generated view (in the example, view 2) still points to this table.

Zero Downtime Option for SAP S/4HANA

Introduction PUBLIC 13
5. At the end of bridge phase, the system needs must be shut down. As with any other upgrade, activities are
required such as:
• cleanup of queues
• descheduling of jobs
• check for erroneous update processes
• logging off all users
• locking the system
6. After the restart of the system, business users are connected back again to the original schema and the
business operations can continue.

2.4 Specific Phases for ZDO

In addition to the phases of a standard update procedure, the following phases are specific to ZDO:

Phase Purpose Comment

PREP_CONFIGURATION/ Configuration of ZDO The administrator is asked if a system backup

SUMASK_ZDO_CONFIGURATION needs to be performed during the system re-
start.

For more information, see Backup Strategy for

ZDO [page 50]

RUN_RSPTBFIL_ZDM_CHECK_BW SAP BW Check Checks for an active SAP BW system. As a re-

sult, the following log messages are possible:

• NO_BW_SCOPE: System scope is

NO_BW_SCOPE, ZDO is supported
• ANALYTICS_ONLY: System scope
is ANALYTICS_ONLY, ZDO is
supported
• DATA_WAREHOUSE: System scope
is DATA_WAREHOUSE, ZDO is
not supported, see SAP note
2707731
• DATA_WAREHOUSE: System scope
is DATA_WAREHOUSE, critical
objects on allow list, ZDO is
possible
For more information, see Error in Phase

RUN_RSPTBFIL_ZDM_CHECK_BW [page
67].

Zero Downtime Option for SAP S/4HANA

14 PUBLIC Introduction
Phase Purpose Comment

PREP_GENCHECKS/ ZDO consistency check for The purpose of the check is to detect inconsis-
PARRUN_ZDO_CONSISTENCY_* ABAP dictionary objects, data- tencies already in the original system at an early
base objects, SLT logging ta- stage as part of the General Checks module.
bles, and SLT triggers
For example, ZDO can only handle database in-
dexes that are defined in the data dictionary. Un-
defined indexes disappear in the target release
when the table is to be cloned. Such indices
must be removed directly or defined in the data
dictionary using the transactions SE11 or SE14.

See also in chapter Known Issues

[page 67] the section Error in

Phase PARRUN_ZDO_CONSISTENCY_CHECK

or RUN_ZDO_CONSISTENCY_CHECK_POST

With Regard To The SLT Setup .

 Caution
If inconsistencies are found during the ZDO
consistency check, you can ignore them and
continue the update procedure with ZDO.
Note, however, that this can lead to conse-
quential errors in the procedure, which may
even require a reset of the Software Update
Manager. We therefore strongly recommend
correcting the inconsistencies instead of ig-
noring them.

Zero Downtime Option for SAP S/4HANA

Introduction PUBLIC 15
Phase Purpose Comment

SUMCHK_ZDO_HTA_HTC Check for SAP HANA reposi- After you start the Software Update Manager,
tory objects, as these objects the system checks for customer-specific SAP
cannot be used for the SUM HANA repository objects for which the following
procedure with ZDO. transport option is used:

• SAP HANA Transport for ABAP (HTA) for

SAP HANA Repository
• SAP HANA Transport Container (HTC)

These customer-specific SAP HANA repository

objects are not accessible during ZDO. If they
are found, a dialog box appears on the interface.
It contains:

• warnings for objects that do not yet exist in

the SAP HANA database
• error messages for objects that exist in the
SAP HANA database and in ABAP.
You can either ignore these error messages
and at the same time accept that these ob-
jects cannot be accessed during ZDO. Or
you can migrate these objects to the SAP
HANA Deployment Infrastructure (HDI) be-
fore you start the upgrade with ZDO.

For more information, see SAP Note

3180989 .

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Test import for ZDO Preparation step required for ZDO table classifi-
GENKEYTRACE cation.

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Implementation of SAP Notes Checks for SAP Note corrections required by
CHECK4NOTES_TOOL_SHD2 in the shadow system SUM in the shadow system. These SAP Notes
belong to the target release.

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Table classification to calculate In phase RUN_RSPTBFIL_ZDM_CLASSIFY, ta-

SUBMOD_LC4BRI_PREP/ the handling of tables during bles are classified as follows on how they are
RUN_RSPTBFIL_ZDM_CLASSIFY the ZDO procedure handled during the upgrade.

• Share: Tables are not affected by the up-

grade
• Clone: Tables are populated with new or ad-
ditional content
• Read Only: Tables to which complex struc-
tural changes are made

A possible business impact can be estimated

with the Impact Analysis [page 23].

Zero Downtime Option for SAP S/4HANA

16 PUBLIC Introduction
Phase Purpose Comment

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Impact analysis by SUM in Analysis of the table classification impact on

SUBMOD_LC4BRI_PREP/ batch mode productive usage statistics regarding tables that
RUN_IMPACT_ANALYSIS_ZDO are modified by after-import methods.

From this phase on, the dialog version of the im-

pact analysis can also be used. For more infor-
mation, see Impact Analysis Usage [page 27].

Start phase: MAIN_BRISETUP/ Rollover to bridge subsystem From this point in time, tables classified as Read
REQ_USER_ROLLOVER_PREP Only become read-only for the bridge subsys-
tem.
Completed with
phase: MAIN_BRITRANS/
REQ_USER_ROLLOVER_FINAL

MAIN_SWITCH/EU_SWITCH_ZDM Smart switch SUM renames the original tables classified as

Clone tables.

MAIN_SWITCH/ Fast data copy transfer Creation of live clone tables.

SUBMOD_LC4BRI_EXEC/
SQLRUNTASK_FDCT_TRANSFER

MAIN_NEWBAS/SUBMOD_ZDO_REPLAY/ Replay phases Replay of the changes created during the run-
RUN_ZDOREPLAY_REPLAY_LKPM time of phase SQLRUNTASK_FDCT_TRANSFER.

MAIN_POSTPROC/ Illegal access check Checks for illegal table access from the upgrade
SUBMOD_BRIDGE_POSTPROC/ subsystem.
RUN_PREP_CHECK_ILLACCESS

Start phase: MAIN_POSTPROC/ End of bridge subsystem Roll back to the productive system and system
SUBMOD_BRIDGE_POSTPROC/ restart. The target release becomes active after
REQ_USER_ROLLBACK_PREP the system restart.

If you have chosen in phase

SUMASK_ZDO_CONFIGURATION that a
backup has to be requested, you are
prompted in phase MAIN_POSTPROC/
SUBMOD_BRIDGE_POSTPROC/
REQ_ZDO_SYSTEM_BACKUP to per-
form the complete system backup

Completed with
phase: MAIN_POSTPROC/
SUBMOD_BRIDGE_POSTPROC/
REQ_USER_ROLLBACK_FINAL

Zero Downtime Option for SAP S/4HANA

Introduction PUBLIC 17
Phase Purpose Comment

RUN_ZDO_SLT_IMPANA_CONSISTENCY Consistency check of the num- This phase includes a check of the number of

ber of SLT triggers SLT triggers in the tables in the statistics file
ZDIMPANA.ZIP and in the current SAP sys-
1. in file ZDIMPANA.ZIP
tem. A discrepancy can be due to a different
provided for the Impact
setup of the SAP system from which the statis-
Analysis [page 23], and
tical data is exported (typically the productive
2. in the system on which
system) and the current SAP system. If at least
the Software Update Man-
one of the systems contains SLT triggers, the
ager runs
Software Update Manager stops. You can ignore
the error if the discrepancy is intentional.

Zero Downtime Option for SAP S/4HANA

18 PUBLIC Introduction
3 Planning

This part of the document contains information about the planning of your update procedure using the ZDO of
SUM.

1. Project Planning Aspects [page 19]

2. Impact Analysis [page 23]
3. Restrictions During the Runtime of the Bridge Subsystem [page 32]

3.1 Project Planning Aspects

This part of the document contains information about basic project planning aspects.

1. Test Cycles [page 19]

2. Exemplary High-Level Project Plan [page 20]
3. Additional Steps for ZDO [page 21]
4. Estimation of the Right Time for Rollover and Rollback [page 22]

3.1.1 Test Cycles

Before you execute an update using the Zero Downtime Option in your productive system, plan and prepare the
project by performing several test cycles.

The first cycle is essential for the overall success of the project. On this basis, you assess if ZDO is the right
approach for your update project.

 Recommendation

We strongly recommend running the first cycle in a sandbox system, ideally built from an up-to-date
system copy of the production system. Running the first cycle on a sandbox system has the following
purposes:

• You familiarize yourself with the technical approach of the Zero Downtime Option
• You specify the expectations for the business downtime
• You validate the bridge subsystem from a technical perspective
• You perform business validation tests in the sandbox system to verify the functionality of all core
business processes during the bridge phase
• You analyze potential conflicts between update and production using the Impact Analysis [page 23]
• You create an update cookbook

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 19
3.1.2 Exemplary High-Level Project Plan

This chapter deals with a high-level project plan as an example for 3-level system landscape.

The following exemplary project plan is a high-level project plan for a system landscape with 3 levels including
all systems from sandbox to production. It is highly recommended using the same update approach (that is,
standard update, nZDM, or ZDO) across the system landscape.

Cycle 1 and cycle 2 can be combined into one test cycle that focuses on both, the technical validation of the
ZDO procedure and the functional validation of the source release when running on a bridge subsystem.

 Note

Check the results of cycles 1 and 2 carefully. Especially, the results of the impact analysis must be
interpreted and discussed with the respective functional teams. Based on the findings, you make a Go
or No Go decision for the further ZDO project.

ZDO is used for all systems including development and quality assurance or test systems. The last cycle before
production must run on an up-to-date copy of production to ensure that all potential issues that can occur in
production are found.

Zero Downtime Option for SAP S/4HANA

20 PUBLIC Planning
3.1.3 Additional Steps for ZDO

This section deals with some steps to be considered in addition to the standard update procedure using SUM.

Installing SUM Toolbox

The SUM Toolbox is mandatory. It must be installed on every system that is updated with ZDO. Before you start
the update procedure, make sure that the latest version of the SUM toolbox is available in each system in the
system landscape and in the sandbox system.

For more information about the SUM toolbox, see SAP Note 3092738 .

Interpreting the Results of the Impact Analysis

This step is essential and must not be skipped. If you ignore the results, a serious business impact on
production can occur if unchecked business-relevant tables are set to read-only For more information, see
Impact Analysis at a Glance [page 23].

Functional Validation During the Bridge Runtime on a Non-Productive

System

We recommend testing all business processes that must be available for daily operation on the bridge
subsystem. For this, the source release must be validated again. Compared to standard upgrades, where only
the target release is tested, the test effort can increase significantly.

Considering Load Verification

As with the functional validation, it is recommended to trigger a load check in a non-productive system during
the time when users are working on the bridge subsystem. From the upgrade tool perspective, there is no
requirement to have real users in the system. The load can also be generated with any load generation and test
tool.

Testing the Database Replication Setup

Database triggers used by SAP Landscape Transformation (SLT) scenarios require more attention for ZDO. For
more information, see SLT Database Trigger Handling in ZDO [page 39].

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 21
  Recommendation

If SLT is used on a productive system, we strongly recommend performing this test already as part of the
first sandbox iteration.

3.1.4 Estimation of the Right Time for Rollover and Rollback

This section deals with the estimation of the right time for rollover and rollback.

We recommend performing the rollover to the bridge subsystem outside the peak hours. Some steps after the
rollover, such as the smart switch in the EU_SWITCH_ZDM phase, need an exclusive database lock on the table
to switch the table spontaneously.

Analyze the system load (dialog and batch load) and the alignment of the rollover to the bridge subsystem best
in close collaboration with the functional teams. As of this point in time, read-only restrictions are active for the
read-only tables.

Also calculate the rollover to the bridge subsystem based on the runtimes from the last pre-production text
cycle performed with an up-to-date copy of the production.

 Example

Example of a runtime analysis and a time estimation:

Assuming, as per the upgrade analysis file (upgana.xml), the net-runtime of the bridge subsystem in the
dress rehearsal cycle took approximately hours. Add then a buffer to calculate the recommended runtime of
the bridge subsystem in production.

If the net runtime of the bridge subsystem in the last test cycle took some hours according to the upgrade
analysis file (upgana.xml), add to the calculated runtime of the bridge subsystem in production a buffer.

 Recommendation

To calculate the productive bridge runtime, add approximately 24 hours buffer runtime to the net runtime.
Example:

• Bridge runtime in last test cycle: 2 hours

• Recommended runtime in production: at least 26 hours

Zero Downtime Option for SAP S/4HANA

22 PUBLIC Planning
Furthermore, check when the cutover shall take place.

 Example

In this example, the cutover and restart of the system is planned for Saturday morning 06:00 am:

The recommended minimum runtime of the "Bridge" subsystem is about 26 hours, therefore you can now
calculate time for the transition to the bridge. In the example, the system has a low system load every
Thursday at 4 pm. Since the delta between this time and the planned restart time is 38 hours, which is
longer than the recommended 26 hours, all requirements are met.

 Note

There is no maximum runtime of the bridge subsystem. As long as there are no business constraints, you
can extend the bridge runtime to meet your project requirements.

3.2 Impact Analysis

This part of the document contains information about the impact analysis for ZDO.

1. Impact Analysis at a Glance [page 23]

2. Exporting Table Statistics to the Productive System [page 26]
3. Impact Analysis Usage [page 27]
4. Applying Best Practice for Impact Analysis [page 31]

3.2.1 Impact Analysis at a Glance

This section deals with the impact analysis as a preparatory step for an update with ZDO.

Performing an update with a downtime-optimization approach can have an certain impact on the ongoing
business operations of the bridge subsystem. Therefore, impact analysis is an important step in preparing the
update procedure with ZDO.

The following impacts need to be considered::

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 23
• Read-only restrictions for users on the bridge subsystem:
Read-only restrictions apply on table level. If a table is reported as read-only in the impact analysis, it
means that users and processes working on the bridge subsystem cannot write into the table anymore.
They will receive an error message or in exceptional cases a dump if they try to write to the table. The
read-only restrictions are in place during bridge runtime, for example from rollover to bridgesubsystem to
the completion of the restart of application servers. Any process that requires wirte-access to a read-only
table cannot be executed during bridge runtime.
• Database triggers such as SLT triggers:
Database triggers which are not ZDO compliant need to be removed before the rollover to the bridge
subsystem. Additionally, if SLT is used, initial load might be required for tables after the upgrade is
completed.
• Additional free space on the database required for the cloned tables:
Some tables have to be cloned during ZDO procedure. This requires additional database space.
• Tables that are smart-switched but have a high number of changes:
Some tables have to be exchanged "on the fly" during the upgrade, the so-called smart-switch. Productive
operation is not affected by the switch. If a table which needs to be switched, is permanently in use, the
switch cannot be performed and SUM stops on error. You can use the DB Table Lock Analyzer feature in
SUM Toolbox to identify a timeframe in which the load on the table is minimal.

To identify these impacts in advance, you can export table statistics from your production system and provide
them to Software Update Manager in the first test cycle run in the sandbox system. The impact analysis can
predict what happens when the defined update scope is applied in the production system.

The results of the impact analysis are based on the following factors:

• The defined scope (list of software components as well as source and target state of software component
versions) must be identical in all systems. If the stack definition is changed, the result also changes.
• The exported table statistics represent the business operations on the bridge subsystem. All relevant
business processes are included according to the exported statistics file. For more information about
project planning aspects, see Project Planning Aspects [page 19].

The analysis is based on statistical data from the production system as the user activities take place in this
system. For this purpose, a tool must be provided in the production system that enables the export of the
statistical data. This data is then analyzed either in a special phase in SUM or by a dialog report in the system.

Part of the update is the table classification in phase RUN_RSPTBFIL_ZDM_CLASSIFY, which calculates how
the tables are handled during the update. Both customer-specific and SAP-delivered tables are included.

The most important table classification types are:

Table Classification Type Example Comment

Shared The update does not change the table The tables are not cloned. There are no
or only adds a new non-key field. restrictions.

Clone The update provides table content or a Additional database space is needed for
structural change. the table clone, and the change record
and replay. There are no restrictions.

Zero Downtime Option for SAP S/4HANA

24 PUBLIC Planning
Table Classification Type Example Comment

Clone read-only The update provides a complex struc- Additional database space is needed for
tural change, or an XPRA accesses the the table clone, and the change record
table. and replay. The table is read-only for
users for the time when they work on
the bridge subsystem.

To identify ZDO-related table restrictions, the impact analysis combines table statistics exported from your
production system with the ZDO table classification result in the system where SUM is running.

For more information about the impact analysis for ZDO, refer to SAP Note 2402270 : Executing Impact
Analysis for Software Update Manager maintenance scenarios

Overview on Reports and Tools Related to Impact Analysis

The following list contains all relevant reports and tools for the impact analysis and their main purpose.

Delivered with SUM 2.0 Tool Import (Will Be Deleted After the Upgrade)
Report Purpose

RSUPG_RUN_IMPACT_ANALYSIS Used by the Software Update Manager in batch mode in

phase RSUPG_RUN_IMPACT_ANALYSIS

Tools Delivered with SUM Toolbox (SAP Note 3092738)

Tool Purpose

Export data for impact analysis Export of table statistics of the production system to a com-
pressed file (such as zdimpana.zip)

Export of SUM classification data Export of table classification data of the Software Update
Manager (such as puttb_shd.zip)

Impact Analysis Dialog version of the impact analysis that can be

used in the system upgraded with ZDO after phase
RUN_RSPTBFIL_ZDM_CLASSIFY is completed

For more information, see the following SAP Community blogs:

• Impact Analysis as part of Software Update Manager 2.0

• Software Update Manager Toolbox is Available Now

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 25
3.2.2 Exporting Table Statistics to the Productive System

The table usage statistics is representative for the time when the update is performed. In particular, it's
important to consider the time when business users are working on the bridge subsystem.

Context

An ideal dataset covers a period of time with all activities and business processes, such as the time in the week
when SUM performs the update. To export table size information, make sure that the database statistics are
up-to-date. Outdated database statistics can result in inaccurate size values.

 Note

The export tool is delivered as part of the Software Update Manager Toolbox. For more information, see:

• SAP Note 3092738 : Software Update Manager Toolbox - Central SAP Note
• Blog Software Update Manager Toolbox is Available Now
• Blog Impact Analysis as part of Software Update Manager 2.0

Execute the tool Export data for Impact Analysis in transaction SUMTOOLBOX to export the
statistical data to the productive system.

Procedure

1. Call transaction SUMTOOLBOX.

2. Execute the tool Export data for Impact Analysis to export the statistics to the file
ZDIMPANA.ZIP.
3. Check for periods that are not flagged as Contains Imports to avoid false positives in impact analysis.

For example, if you perform daily imports into the productive system, you cannot select a period. In this
case, you must continue with the selection of periods that are flagged as Contains Imports.

If you export a large period of time, such as a month or more, it is possible that you also export statistics
about table accesses that are not necessarily relevant to the business processes needed during the
runtime of the bridge subsystem.
4. Provide the exported file ZDIMPANA.ZIP to your download directory.

 Note

If SUM already stopped on error in phase RUN_IMPACT_ANALYSIS_STBX_CHECK, follow the

instructions as described in the SAP Note 2471883 .

Zero Downtime Option for SAP S/4HANA

26 PUBLIC Planning
3.2.3 Impact Analysis Usage

This section deals with aspects of the impact analysis usage.

If you keep the default selection for all fields, the statistics file ZDIMPANA.ZIP located in your download
directory is used.

Starting the Impact Analysis

There are two possibilities to run the impact analysis:

1. In batch mode: The Impact Analysis is called during a SUM run in phase RUN_IMPACT_ANALYSIS_ZDO.
This phase uses the file ZDIMPANA.ZIP.
2. As a dialog from the SUM toolbox: The impact analysis of the delivered as part of the Software
Update Manager Toolbox. For more information, see SAP Note 3092738 . After the phase
RUN_RSPTBFIL_ZDM_CLASSIFY is completed, it can be called in dialog mode.

Evaluating the Impact Analysis

 Note

The evaluation of the impact analysis cannot be called until the RUN_RSPTBFIL_ZDM_CLASSIFY phase is
completed.

If something is found, SUM stops in phase RUN_IMPACT_ANALYSIS_ZDO with an error message:

Log file for phase RUN_IMPACT_ANALYSIS_ZDO: <DIR_PUT>/SUM/abap/log/IMPANAUPG.<SID>

The results need to be checked in detail, which takes a while. Therefore, you can ignore the error at this time
by selecting Ignore phase errors and proceed to next phase. While SUM continues with the update, check every
single result of the impact analysis carefully.

You have two options to perform the check:

• Read the text-based log file output.

• Use the dialog mode of the impact analysis in SUM Toolbox.

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 27
Impact Analysis Output in SUM Toolbox

In the following, you see an example of an impact analysis output triggered in the dialog mode:

The user interface is divided into five sections:

Zero Downtime Option for SAP S/4HANA

28 PUBLIC Planning
Section Purpose

(1) File Selection Displays the relevant data for performing the impact analy-
sis.

The following three scenarios are covered:

1. Impact analysis on the system where a ZDO upgrade

procedure is active.
• The source for the table classification data is the
database table in the system that contains this in-
formation.
• The source for the table statistics is the file
ZDIMPANA.ZIP located in your download direc-
tory.
2. Impact analysis on the system where a ZDO upgrade
procedure is active, but using a new table statistics file.
• The source for the table classification data is the
database table in the system that contains this in-
formation.
• The table statistics are uploaded via SAP GUI.
3. Remote impact analysis on any other system of the
same system landscape as, such as development sys-
tem.
• The table classification data has been exported
via SUM toolbox from a system where the ZDO
upgrade procedure is completed. The output file
PUTTB_SHD.ZIP is uploaded via SAP GUI.
• The table statistics are uploaded via SAP GUI.

(2) Header Displays information such as export date, source system ID,
number of evaluated days, and whether software changes
such as importing shipments are included during the ex-
ported time.

(3) Overall Summary Displays the total number of cloned tables, read-only tables,
and additional database space for cloned tables. It also dis-
plays the total change volume for all tables in the system,
and the online replication volume for cloned tables per day.
These numbers help you to better understand the ratio of
cloned tables compared to the total number of changes in
the system.

(4) Impact Analysis Findings Summarizes and aggregates the issues. Also, gives an es-
timate on the required database free space for the clone
tables.

(5) Result table in ALV grid Displays results at severity, category, and table level.

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 29
  Note

Check the result table carefully as these findings can be relevant and critical when you perform an update
with ZDO in the productive system.

Possible Categories

Category Comment

Read-only The most critical category that always has to be checked in

detail.

The table is used in the productive system according to the

provided statistics, but is read-only during the runtime of the
bridge subsystem.

Triggers Impact analysis uses the statistics file from the production
system to determine database triggers. If database triggers
exist in the production system that are not supported by
ZDO, they must be deleted before the rollover to the bridge
subsystem as follows:

• SLT triggers must be deleted in phase

RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_AFT.
• All other triggers can be deleted in phase
REQ_USER_ROLLOVER_FINAL.

Tables with SLT triggers that require a reload after the re-
start are also listed in this category.

For more information, see Handling of Database Triggers

(Including SLT Replication) [page 39] and SLT Database
Trigger Handling in ZDO [page 39].

Cloned Large tables that are cloned.

Smart-switch Tables that are cloned, but changed frequently in produc-

tion.

All clone tables are renamed in phase EU_SWITCH_ZDM,

which requires an exclusive lock. However, the more changes
a table has, the more difficult it is to get an exclusive table
lock.

Comp. view Tables that receive a new non-key field can be kept as
"shared". The bridge subsystem only sees the old fields us-
ing a compensation view.

The new field is added during the upgrade in phase

PARCONV_UPG. This requires an exclusive table lock.

Zero Downtime Option for SAP S/4HANA

30 PUBLIC Planning
Possible Severities:

Severity Comment

Green (square) Uncritical finding. Usually, no further action is required.

By default, these entries are hidden. To display them as well,

click the green button in the ALV Grid menu bar.

Orange (triangle) No immediate action is required. You are only reminded of

a specific message, such as a warning that a table is smart-
switched.

Red (circle) These messages must be checked in more detail with the
business teams, as there is a potential risk to productive
business operations.

3.2.4 Applying Best Practice for Impact Analysis

This section deals with the best practices for the impact analysis.

Context

The impact analysis called by SUM during the update runs in batch mode and evaluates a single record
provided with file ZDIMPANA.ZIP.

However, it can be an advantage to perform the impact analysis with different periods of time. This helps to
identify tables that are irrelevant or non-critical for the point in time when the update is scheduled to run in the
production system.

Some tables that are set to read-only by the update can only be used for a single business process that is likely
to run in the first week of a month. However, if the update is planned for the third week of a month, this table
can also be considered as non-critical.

Ideally, you follow this best practice already in the sandbox system, where the first test cycle of the update with
ZDO project is performed.

Procedure

1. As a preparation, execute the export of table statistics with the SUM Toolbox in the production system.

Make sure that the time period represents the uptime on the bridge subsystem, and run the tool Export
data for Impact Analysis in the SUM Toolbox several times.

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 31
  Example

You run the export in calendar weeks 20, 21, 22, and 23. As a result, four separate ZIP files are created.
(Note: If you use the dialog version for the impact analysis, you do not have to follow a specific naming
convention for these files.)

For more information, see Exporting Table Statistics to the Productive System [page 26].
2. Execute the tool Impact Analysis with the SUM Toolbox in the sandbox system.

Make sure that at least phase RUN_IMPACT_ANALYSIS_ZDO is reached.

3. In the file selection screen of the impact analysis, choose the F4 help to upload the table statistics via SAP
GUI.
4. Export the result list into a spreadsheet.
5. Perform steps 3 and 4 again for each table statistics file.
6. Consolidate the results of the impact analysis into a single spreadsheet.
7. Check whether tables are displayed only once or regularly.
8. Try to identify false positive results that could have been caused by an import of transports or an irregular
process.

3.3 Restrictions During the Runtime of the Bridge

Subsystem

During the runtime of the bridge subsystem, some restrictions must be considered.

• Read-Only Mode for Some Tables [page 32]

• Maintenance Mode in SUM [page 33]
• Native Database Connections to the Original Database Schema [page 33]
• Archiving [page 34]

Read-Only Mode for Some Tables

During the bridge phase, ZDO sets some tables to read-only mode for the following different reasons:

• a complex structural change

• a conflicting table access by XPRA, XCLA, or After Import Method in phase XPRAS_AIMMRG
• a technical restriction because of the ZDO procedure

Normally, a read-only table does not affect the productive use of the system. The Impact analysis can detect
possible read-only conflicts already during text cycles in the sandbox system. For more information, see Impact
Analysis Usage [page 27].

Zero Downtime Option for SAP S/4HANA

32 PUBLIC Planning
Maintenance Mode in SUM

The update procedure with ZDO runs according to the maintenance mode of SUM. This means that the
following update-related restrictions of the maintenance are active during the ZDO procedure:

Workbench lock As in the standard update procedure, the system is locked

against the creation, modification, and deletion of Work-
bench objects after the LOCK_EU phase has been reached.

Transport lock As in the standard update procedure, the system is locked

against the import of transport requests after reaching the
phase LOCK_EU.

Customizing lock The system is locked against customizing changes. Excep-

tions to this are changes made during the runtime of the
bridge subsystem as Current settings.

 Note
• In productive environments, it is not a restriction,
because the customizing is not changed directly in
the productive system.
• Customizing that has been modified in the bridge
subsystem to match the Current settings can cause
unexpected dumps because the corresponding ta-
bles are set to read-only during by the ZDO proce-
dure.

Transaction RZ10 The transaction RZ10 is disabled during operations on the

bridge subsystem. For more information, see SAP Note
2007911 .

Number ranges Changes to number range intervals are not allowed during
operations on the bridge subsystem. This can lead to incon-
sistencies in number assignment.

Native Database Connections to the Original Database Schema

As described in Technical Details of the Zero Downtime Option [page 11], the database schema changes during
the rollover to the bridge subsystem.

If an external application or system uses native database connections to the original database schema (such
as SAPHANADB), the application is connected to the data belonging to the target release during the runtime of
the bridge subsystem. Therefore, all native database connections must be disconnected as soon as the rollover
to bridge is carried out in phase REQ_USER_ROLLOVER_PREP.

The connection can be re-established after the restart as soon as the phase REQ_USER_ROLLBACK_FINAL is
reached.

Zero Downtime Option for SAP S/4HANA

Planning PUBLIC 33
Archiving

Archiving is not supported during the runtime of the bridge subsystem. The reason is that archiving processes
also delete a significant number of entries from tables that are relevant for ensuring the consistency of the
bridge and upgrade subsystem. As a consequence, this leads to an unplanned runtime extension of certain
SUM phases.

Zero Downtime Option for SAP S/4HANA

34 PUBLIC Planning
4 Preparation

This part of the document contains information about the preparatory activities for your update procedure
using the ZDO of SUM.

1. Hardware Requirements Check [page 35]

2. High-Availability Setup [page 36]
3. Add-On Handling [page 36]
4. Preliminary Checks [page 37]
5. Handling UPL Data Collection Job [page 37]
6. SAP Business Warehouse Extractor Handling [page 38]
7. Silent Data Migration Handling [page 38]
8. SLT Database Trigger Handling in ZDO [page 39]
9. Usage of Custom Database Schemas [page 48]
10. Backing Up Table Content in the SAP HANA Repository 1.0 [page 48]
11. Migration of Native SAP HANA Database Objects [page 49]
12. Backup Strategy for ZDO [page 50]

4.1 Hardware Requirements Check

CPU, Main Memory, Disk, and Swap Space

In general, the hardware requirements are the same as for the near-Zero Downtime Maintenance approach.
Make sure that there is enough temporary disk space available in the file system for the ZDO update because
large files are written temporarily to disk during some phases.

 Note

We recommend that the file system with the SUM directory has about 100 GB more disk space for the ZDO
procedure than is required for the standard update.

See also in the SUM Guide the chapter Preparation Checking the Hardware Requirements .

Space Requirements in the Database

Make sure that enough temporary and permanent free space is available in your database. In addition to the
requirements from the standard update, ZDO requires free database space for the clone tables. The additional

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 35
free space cannot be quantified beforehand because it depends on the scope of maintenance and on the size of
the system.

However, if you already run the impact analysis in the first test cycle in the sandbox system, a projection
is done by cumulating the sizes of the clone tables. This calculation is based on the provided statistics file
ZDIMPANA.ZIP.

For more information, see Impact Analysis at a Glance [page 23].

4.2 High-Availability Setup

This section covers the update of SAP systems with a high availability (HA) setup.

ZDO for SUM supports the update of high availability systems. The prerequisite is that the HA setup is set up
correctly, that is, file systems such as DIR_PROFILE are also present on the bridge subsystem and are checked
for functioning before starting the update. There are no further requirements for the HA system from ZDO side.

 Note

We highly recommend setting up the same HA solution in a non-productive environment.

During the update with ZDO, a dialog in the phase SUM_ASK_ZDO_CONFIGURATION asks you whether you want
to switch to HA maintenance mode for further execution. If you want to use this mode, and your system is
installed with an HA switch-over environment, make sure that the failover capabilities of the cluster switch-over
software are disabled in the target release during the cutover and rollback to the original system. The Software
Update Manager stops for this in the phase REQ_USER_ROLLBACK_PREP.

For more information about how to prepare the ASCS instance for downtime, see the SUM 2.0 Guide. Navigate
here to 6 Running the Software Update Manager 6.2 Actions During the Roadmap Steps Preparing the
ASCS Instance for the Downtime (HA Only) .

4.3 Add-On Handling

This section deals with the handling of add-ons by ZDO.

• All installed add-ons in the system must be ZDO compliant to perform an update with the ZDO
functionality. See SAP Note 2707731 for a list of add-ons that are not enabled for ZDO.
• If you have add-ons in the system that are not enabled for ZDO, you can request a customer-specific
project. For more information, see section 6. Registration Process for Customer-Specific Projects of SAP
Note 2707731 .

Zero Downtime Option for SAP S/4HANA

36 PUBLIC Preparation
4.4 Preliminary Checks

In addition to other tools, the Software Update Manager Toolbox software also includes a tool ZDO Preliminary
Checks.

Before the Software Update Manager is started, you can use the ZDO preliminary checks to verify that the
system can be updated with the Zero Downtime option of the Software Update Manager.

The checks must be performed in all systems that are to be updated with ZDO. Start with the sandbox system,
which is ideally a recent copy of your production system to get the most benefit from the checks.

The focus of the preliminary checks is on the following topics:

• Use of the SAP Business Warehouse

• Status of the Silent Data Migration infrastructure
• Consistency check of data dictionary and database
• Consistency check of SAP HANA content deployment
• Consistency check of active nametab objects
• Verification of ZDO compliance of SLT setup

For more information about the SUM Toolbox, see SAP Note 3092738 .

For more information about the ZDO Preliminary Checks, see the SAP Community blog Introducing the ZDO
Preliminary Checks as part of SUM Toolbox .

4.5 Handling UPL Data Collection Job

The section covers the handling of the data collection job of Usage & Procedure Logging UPL.

Context

If (UPL) is activated in your system, the data collection job /SDF/UPL_PERIODIC_EXT_JOB runs daily,
extracts data from table COVRES, and deletes its content by processing the table either with the Truncate
or with the Drop/Create option. Since this operation is incompatible with ZDO, it must be deactivated. Proceed
as follows:

Procedure

1. Deactivate the batch job before phase MAIN_BRISETUP/REQ_USER_ROLLOVER_PREP.

• For local instances of batch job /SDF/UPL_PERIODIC_EXT_JOB, use report /SDF/UPL_CONTROL.
• If UPL is triggered by your Solution Manager system, proceed as follows:

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 37
 1. Log on to your Solution Manager system.
2. Call transaction SOLMAN_SETUP.
3. In the list of scenarios, expand the subtree Cross Scenario Configuration and select Usage Logging.
4. In section Configure Usage Logging, select the rows that belong to your ZDO target system.
5. Choose Deactivate Selected.
2. Reactivate the batch job after SUM phase MAIN_POSTPROC/SUBMOD_BRIDGE_POSTPROC/
REQ_USER_ROLLBACK_FINAL.
• For local instances of batch job /SDF/UPL_PERIODIC_EXT_JOB , use report /SDF/UPL_CONTROL.
• If UPL is triggered by your Solution Manager system, proceed as follows:
1. Log on to your Solution Manager system.
2. Call transaction SOLMAN_SETUP.
3. In the list of scenarios, expand the subtree Cross Scenario Configuration and select Usage Logging.
4. In section Configure Usage Logging, select the rows that you deactivated previously.
5. Choose Activate Selected.

4.6 SAP Business Warehouse Extractor Handling

Long running SAP Business Warehouse (SAP BW) extractor queues can lead to lock situation in certain phases
of the update.

The following phases acquire exclusive locks on database tables that are processed in the respective phase:

• EU_SWITCH_ZDM
• SQLRUNTASK_LC4BRI_CRETRIGGER
• SQLRUNTASK_FDCT_TRANSFER
• PARMVNT_XCNV
• PARCONV_UPG

In general, we recommend deactivating SAP BW extractors during the bridge phase.

4.7 Silent Data Migration Handling

The Silent Data Migration Infrastructure (SDMI) is a framework that enables automatic
application data migration during system uptime.

The migration of application data usually takes place in the course of release upgrades or updates during
downtime. However, the SDMI also supports update or upgrade procedures with zero downtime option, so that
silent data migrations can run in parallel to regular productive business operations after the procedure.

Before you start an update or upgrade procedure with zero downtime option, make sure that all relevant
silent data migration classes have been executed successfully. With transaction SDM_MON, you can display
all relevant classes for silent data migration across all clients in the system. If any unfinished silent data

Zero Downtime Option for SAP S/4HANA

38 PUBLIC Preparation
migration classes exist, the Software Update Manager stops with an error in phase PREP_GENCHECKS/
RUN_SDM_CHECK_STARTRELEASE.

 Example

Excerpt from the log file UPG_SDM_CHK_STARTRELEASE.<SID> in case of an error:

2EETG010 "SDM has unfinished migration" "CL_SDM_POCR_CORRECT_KPIS" "in client

000" "and SAP Note 2691264 can help"
4 ETG011 " "
2EETG010 "SDM has unfinished migration" "CL_SDM_POCR_CORRECT_KPIS" "in client
300" "and SAP Note 2691264 can help"

The procedure can only be continued if all relevant classes for silent data migration are completed.

For more information about the Silent Data Migration Infrastructure (SDMI), see:

• the SAP Help Portal at https://help.sap.com/viewer/

a72da595f6a0485f8ad1a30851c2e314/201909.000/en-US/a9e0718f5277446285758e6c94e5abc5.html
• the upgrade guides for SAP S/4HANA 2020 or higher at https://help.sap.com/viewer/product/
SAP_S4HANA_ON-PREMISE. Choose Implement Upgrade Guide .

4.8 Handling of Database Triggers (Including SLT

Replication)

ZDO does not support database triggers other than those triggers used for SLT replication based on Remote
Function Control (RFC) technology. For more information on SLT triggers, see SLT Database Trigger Handling
in ZDO [page 39].

All other triggers must be removed before the rollover to the bridge subsystem. A list of triggers that must be
removed provides the impact analysis. The application of which is described in Impact Analysis Usage [page
27].

4.9 SLT Database Trigger Handling in ZDO

Introduction

When you are updating or upgrading an SAP S/4HANA system using ZDO, the replication of changes using
SAP Landscape Transformation Replication Server (SLT) is supported. SLT replication can also be used as a
part of SAP Data Intelligence and Operational Data Provisioning. It is essential to identify the replication type.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 39
  Note

Only RFC-based replication is supported by ZDO. Replication using native database connections cannot be
determined by Software Update Manager. For more information about the different SLT replication types,
see SAP Note 1605140 .

We distinguish between the following four case scenarios:

• Case Scenario 1: No SLT replication: SLT is not used in any system to be upgraded using ZDO. SLT-
specific considerations are not relevant.
• Case Scenario 2: Software Update Manager execution without SLT replication: SLT is used in
production. The current system that is being upgraded (for example, a sandbox system) does not have
an SLT setup. In that case, there is no special handling of SLT by the Software Update Manager in the
current system. This difference will be brought up by the Software Update Manager. Also, the Impact
Analysis outlines the tables on which SLT triggers cannot be preserved during the rollback to the original
system.
• Case Scenario 3: Subscription-based change data capture mechanism is used: SLT is set up in
production using the subscription-based change data capture mechanism. The current system has the
same SLT setup as production. SLT replication continues during the Software Update Manager uptime on
the bridge sub-system by default. For more information about the handling of SLT by the Software Update
Manager, see sub-section Case Scenario 3: Subscription-Based Change Data Capture Mechanism [page
42].
• Case Scenario 4: Legacy change data capture mechanism is used: SLT is set up in production using
the legacy change data capture mechanism (or a mixed scenario with subscription-based change data
capture mechanism). The current system has the same SLT setup as production. The handling of SLT by
the Software Update Manager depends on whether SLT replication is supposed to be active during the
uptime on the bridge sub-system. For more information, see sub-section Case Scenario 4: Legacy Change
Data Capture Mechanism [page 43].

 Note

Depending on the source system and SLT server configuration, there are two different technologies used
by SLT replication. Database triggers having the prefix /1LT/ are using the legacy change data capture
mechanism. The subscription-based change data capture mechanism is used by triggers having the
prefix /1DH/. This is possible as of SAP S/4HANA 2020.

Case scenarios 3 and 4 are relavant and described in the following sub-sections:

• Case Scenario 3: Subscription-Based Change Data Capture Mechanism [page 42]

• Case Scenario 4: Legacy Change Data Capture Mechanism [page 43]

Reduction of SLT Observer Job Runtime

If a new SLT replication is used, reduce the runtime of the /1DH/OBSERVE_LOGTAB job from 60 minutes
(default) to 10 minutes or less to avoid a time-out in the Bridge Reconnect phase. To verify if you can have

Zero Downtime Option for SAP S/4HANA

40 PUBLIC Preparation
new SLT triggers in your system check if the class CL_DHCDC_ZDO_UPGRADE_FACADE exists. You can change
the runtime in the maintenance view of table DHCDC_JOBSTG with the following attributes:

 Caution

The value change does not affect a currently running observer job.

For more information on managing your SLT replication, see the chapter Managing the Replication Process
Using Transaction LTRC in the guide SAP Landscape Transformation Replication Server. You can access it on
the SAP Help Portal at https://help.sap.com/sapslt. Choose Use Application Help SAP Landscape
Transformation Replication Server . Navigate in the guide to section Replicating Data to SAP HANA.

Initial Load After Phase REQ_USER_ROLLBACK_FINAL

After the rollback in phase REQ_USER_ROLLBACK_FINAL, some SLT tables can require an initial load. This is
not required for all cloned tables because the number of tables that require an initial load within the processing
is reduced by a special handling.

However, there are still tables left for which an initial load is required because they have an unsupported
structure change, such as a key change, or an SLT table is a basis exchange table.

Therefore, check after phase REQ_USER_ROLLBACK_FINAL for tables that require an initial load and start it.

Validation of SLT Handling with ZDO in a Non-Production Run

If SLT is configured for the production system, we strongly recommend performing a ZDO with SLT test run
in a nonproduction system beforehand. This run allows you to become familiar with the SUM phases and the
required manual activities as previously described in this chapter. It also ensures that the impact analysis
results related to SLT tables match in the test and production run.

For more information, see the document Considerations When Testing the SAP S/4HANA Upgrade Process.
You can access it on the SAP Help Portal at https://help.sap.com/sapslt. Choose Operate Additional
Information .

 Note

• If you have questions about the SLT test setup, report an incident on component CA-LT-SLT.
• If SLT is set up in the current system differently than in the production system, the dialog in phase
SUMASK_RFC_2_SLT_SERVER can differ as follows:
• If SLT triggers with prefix /1LT/ exist, the RFC destination is prompted.
• If the SLT server is remote and not local, the RFC destination must be specified.
• If only SLT triggers for the subscription-based change data capture mechanism with prefix /1DH/
exist in the system, no dialog is displayed.
• To ensure that SUM behaves the same in both runs, select in phase SUMASK_RFC_2_SLT_SERVER the
same options for the test run as for the production run.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 41
Other References

• SAP Note 1605140 - SAP Landscape Transformation Replication Server (SLT)

• SAP Note 2572945 - DMIS compatibility with S/4HANA
• SAP Note 2596411 - Note Analyzer for ABAP-based Migration and Replication Technology […]
• SAP Note 3016862 - Note Analyzers with separated scenarios for ABAP-based Migration and
Replication Technology […]
• User Guide: Considerations When Testing the SAP S/4HANA Upgrade Process

4.9.1 Case Scenario 3: Subscription-Based Change Data

Capture Mechanism
When the Software Update Manager is launched on a system where the subscription-based change data
capture mechanism is used (triggers with prefix /1DH/*) and ZDO is selected as the downtime-optimization
approach, SLT replication is kept active during uptime on the bridge sub-system by default.

The following prerequisites and restrictions need to be met:

• At least SAP HANA revision 2.0.00.42.

• Various SAP Notes that have to be applied in the source system.
• Various SAP Notes that have to be applied in the central SLT server.

 Note

The list of SAP Notes is volatile and gets extended. Therefore, make sure that you always have the latest
SLT-related corrections applied before starting the ZDO upgrade or update. For this, the so-called Note
Analyzer is provided (for more infornation, see SAP Notes 2596411 and 3016862 ). In addition, the
SLT Release Information Notes listed in SAP Note 2572945 provide the full list of all relevant SAP Notes.

Zero Downtime Option for SAP S/4HANA

42 PUBLIC Preparation
This figure shows the Software Update Manager process and highlights relevant phases for a ZDO upgrade with
active SLT replication during bridge execution. This is relevant for setups using subscription-based change data
capture mechanism with /1DH/* triggers. SLT is kept active for the uptime on bridge. Not all triggers can be
preserved. Impact Analysis prints out the full list. For affected tables on which the triggers cannot be preserved
during the restart of the application servers.. An initial load is required after the restart of the application server.

In phase RUN_ZDO_SLT_IMPANA_CONSISTENCY , the Software Update Manager checks whether the tables
with SLT triggers in file ZDIMPANA.ZIP match the tables with SLT triggers in the system on which the
Software Update Manager is running. If there is a discrepancy, the Software Update Manager stops with an
error message. A mismatch might indicate a different setup of the system where statistical data is exported
from (typically production system) and the current system. If the mismatch is intentional, the error can be
ignored.

As part of the ZDO consistency check in phase PARRUN_ZDO_CONSISTENCY_CHECK, the Software Update
Manager verifies if the SLT setup is valid.

The Impact Analysis outlines the tables that have SLT triggers but have to be cloned by ZDO. This helps to
elaborate the amount of tables that have to be reinitialized after the ZDO upgrade.

Shortly before the end-users are transitioned to the bridge sub-system, phase
RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_PRE informs about any non-SLT triggers that need to be dropped.
The phase is equipped with an ignore option. In the next trigger check phase, they have to be deleted.

When the system is restarted, as part of the ramp-up activities, an initial load is needed for all switch, clone,
and XCLA tables having SLT triggers.

 Note

In general, all these tables used to have two different versions during the ZDO upgrade. Only the source
version of the tables was equipped with the SLT trigger. The new version of the tables that belong to the
target release no longer have SLT triggers. Therefore, it is mandatory to perform an initial load for such
tables in the SLT cockpit.

4.9.2 Case Scenario 4: Legacy Change Data Capture

Mechanism
When the Software Update Manager is launched on a system where the legacy change data capture
mechanism is used (triggers with prefix /1LT/*) and ZDO is selected as the downtime-optimization approach,
phase SUMASK_RFC_2_SLT_SERVER in Configuration automatically determines if the system currently being
upgraded uses SLT replication based on SLT triggers found in the system. This applies to cases 4a and 4b, as
described below in this sub-section.

Option 4a: SLT is Kept Active During Uptime on Bridge Subsystem with
Legacy Change Data Capture Mechanism

Checkbox Yes, run ZDO with active SLT triggers in phase SUMASK_RFC_2_SLT_SERVER is checked. To keep the
SLT replication active during the bridge runtime, an RFC destination for each of the connected SLT servers has
to be provided to the Software Update Manager.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 43
Depending on your SLT setup, you are asked in phase SUMASK_RFC_2_SLT_SERVER for a list of RFC
connections from your system that is updated using ZDO to the SLT Server.

Create the RFC destination manually in the source system with the following attributes:

• SAP_IUUC_REPL_ADMIN
• SAP_MWB_PROJECT_MANAGER
• SAP_IUUC_REPL_REMOTE

These RFC destinations are used to prepare the database triggers needed during the bridge runtime. This is
only relevant if SLT triggers from legacy change data capture mechanism with the prefix /1LT/ are used and
determined by the Software Update Manager. Additional prerequisites and restrictions are the following:

• At least SAP HANA® revision 2.0.00.42.

• After the phase SUMASK_RFC_2_SLT_SERVER, it is not allowed to change the SLT replication.
• Various SAP Notes that have to be applied in the source system.
• Various SAP Notes that have to be applied in the central SLT server.

 Note

The list of SAP Notes is volatile and gets extended. Therefore, make sure that you always have the latest
SLT-related corrections applied before starting the ZDO upgrade or update. For this, the so-called Note
Analyzer is provided (for more infornation, see SAP Notes 2596411 and 3016862 ). In addition, the
SLT Release Information Notes listed in SAP Note 2572945 provide the full list of all relevant SAP Notes.

After the completion of the update, you are prompted to delete the RFC destinations in phase
REQ_DEL_RFC_SLT_SERVER.

Zero Downtime Option for SAP S/4HANA

44 PUBLIC Preparation
Option 4b: SLT is Deactivated During Uptime on Bridge Subsystem with
Legacy Change Data Capture Mechanism

If checkbox Yes, run ZDO with active SLT triggers in phase SUMASK_RFC_2_SLT_SERVER is unchecked, the SLT
replication has to be paused or suspended before rolling over to the bridge sub-system.

This image shows the Software Update Manager process and highlights the relevant phases for a ZDO upgrade
with deactivated SLT replication during bridge execution. This is relevant for setups using the legacy change
data capture mechanism with /1LT/* triggers (and mixed scenarios with subscription-based change data
capture mechanism) . SLT needs to be suspended for the uptime on bridge. Additionally, not all triggers can be
preserved. Impact Analysis prints out the full list. For affected tables on which the triggers cannot be preserved,
an initial load is required after the restart of the application server.

In phase RUN_ZDO_SLT_IMPANA_CONSISTENCY, the Software Update Manager checks the number of SLT
triggers on tables as reported in the statistics file ZDIMPANA.ZIP and a number of SLT triggers in the current
system. A mismatch might indicate a different setup of the system where statistical data is exported from
(typically production system) and the current system. If only one of the systems has SLT triggers, Software
Update Manager will stop. If the mismatch is intentional, the error can be ignored.

In phase SUMASK_RFC_2_SLT_SERVER the dialog deciding the SLT handling is displayed.

The Software Update Manager detects that the systems uses SLT replication. However, in phase
SUMASK_RFC_2_SLT_SERVER, the decision was taken that SLT replication should be deactivated during the
bridge runtime.

The Impact Analysis outlines the tables that have SLT triggers but have to be cloned by ZDO. This helps to
elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.

The first SLT check in phase RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_PRE lists the tables for which the SLT
(or other) triggers have to be dropped. This phase is equipped with an ignore option. The triggers can be kept
until the next trigger check phase runs.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 45
Shortly after starting the rollover to bridge, the SLT check phase
RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_AFT runs. Here, the triggers for the tables listed have to be
dropped in order to proceed.

Before the roll-over to the bridge happens, the SLT replication has to be suspended in the SLT cockpit.

When the system is restarted, as part of the ramp up activities, an initial load is needed for certain tables having
SLT triggers as reported in the Impact Analysis. Tables handled as shared by Software Update Manager are not
affected.

4.10 SAP HANA Scale-Out Handling

This section covers important aspects of the SAP HANA scale-out configuration and the handling of the
Optimistic Synchronous Table Replication (OSTR).

Introduction

SAP HANA scale-out combines multiple independent SAP HANA databases into one system. By distributing
a system across multiple hosts (scale-out), the hardware restrictions of a single physical server can be
overcome, and an SAP HANA system can distribute the load across multiple servers.

The SAP HANA database has a scale-out configuration with one main and one or more secondary worker
nodes. Tables are distributed to SAP HANA hosts using table groups that are defined by semantically related
tables. All tables in a table group must be on the same node.

Typically, a table group corresponds to the transactional tables of a specific application. For example, the
large transactional tables for managing financial documents such as ACDOCA or BSEG can be a table group.
Therefore, all tables of a specific application are placed together on one node.

The following figure shows an example of a scale-out configuration on SAP HANA:

Zero Downtime Option for SAP S/4HANA

46 PUBLIC Preparation
An SAP HANA scale-out configuration is automatically detected by Software Update Manager and handled
accordingly. Manual actions are not required. Using the SAP HANA Scale-Out configuration with the Software
Update Manager has no further impact.

To avoid cross-node joins in the database trigger, lock tables and logging tables created by the Software Update
Manager are automatically placed in the same node where the recorded tables exist. The distribution of tables
in the table groups is kept according to the configuration of the source system.

Support of Optimistic Synchronous Table Replication

Some master and configuration data tables have Join relationships with multiple table groups. Therefore, it
is recommended to have copies of these tables on all nodes of the scale-out cluster, for which you can use
the SAP HANA feature of Optimistic Synchronous Table Replication. This setup can reduce network traffic, for
example, when slow-changing master data often needs to be linked to tables that reside on other hosts.

OSTR tables do not support DDL AUTO-COMMIT OFF or certain ONLINE DDL statements. The reason are
dependencies between the statement types DML Data Updates and DDL Table Updates when the replication is
active and the complete transaction has not yet been confirmed.

Because ZDO requires the statement DDL AUTO-COMMIT OFF for the smart switch in phase EU_SWITCH_ZDM,
all replicas enabled by OSTR are deactivated in phase SQLSELEXE_DISABLE_SCALE_REPLICATION before the
smart switch.

As long as OSTR is disabled, all table accesses are redirected to the primary tables. This can have a temporary
negative impact on system performance because the number of cross-node accesses can increase for SQL
joins between tables that are located in different nodes in SAP HANA.

In general, OSTR activation has the following effects:

• The source table is write-protected during a reactivation.

• The synchronization of tables can decrease the system performance.

The following figure shows an overview of SUM phases with enabled OSTR on the original system :

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 47
  Caution

Do not change the OSTR configuration during SUM processing, that is:

• Do not activate or deactivate statuses.

• Do not create new OSTR tables.
• Do not delete existing OSTR tables.

For more information about Hana Scale-Out and OSTR, see the following SAP Notes:

• 2408419 : SAP S/4HANA - Multi-Node Support

• 3135489 : SAP S/4HANA on HANA scale-out: Implementing table distribution
• 2340450 : FAQ: SAP HANA Table Replication

4.11 Usage of Custom Database Schemas

This section deals with the customer-specific database schemas.

You can create own database schemas in an SAP HANA database. However, they are different from SAP HANA
Deployment Infrastructure (HDI) containers. If you only work with HDI containers as described in Migration of
Native SAP HANA Database Objects [page 49], no further action is required.

As described in Technical Details of the Zero Downtime Option [page 11], the database schema changes during
the rollover to the bridge subsystem. This change also implies a change of the database schema user that is
used by the work processes.

To access the custom database schema from the bridge subsystem, make sure that the schema user of the
bridge subsystem (for example, SAPHANADBSHD) has the same authorizations as the original schema user
(such as SAPHANADB) before entering the bridge subsystem.

4.12 Backing Up Table Content in the SAP HANA Repository

1.0

This section deals with the backup of table content in the SAP HANA repository 1.0.

Prerequisites

• You have applied SAP Note 2642660 .

• The SUM procedure has reached REQ_USER_ROLLOVER_FINAL.

Zero Downtime Option for SAP S/4HANA

48 PUBLIC Preparation
Context

The ZDO of SUM offers the option to reset native SAP HANA database objects. For this purpose, back up the
content of tables in the SAP HANA repository 1.0, also known as _SYS-BIC.

Immediately after the phase REQ_USER_ROLLOVER_FINAL is reached, proceed as follows to back up your
tables content:

Procedure

1. Open the SAP HANA Studio and log in with the SYSTEM user to the system on the database and the tenant
where you want to export the table data.
2. Open the SQL console in the database schema _SYS_BIC.
3. To get the list of all table names, enter the following statement:

select TABLE_NAME from tables where SCHEMA_NAME='_SYS_BIC' and

is_user_defined_type='FALSE';
4. For each table, export the data to a specific folder by entering the following statement:

export <table_name> as csv into '<folder_name>' with replace;

4.13 Migration of Native SAP HANA Database Objects

In SAP HANA databases, native SAP HANA database objects are stored in the SAP HANA repository 1.0, also
known as _SYS_BIC. To ensure a proper encapsulation of the source and target releases during updates with
ZDO, the database objects and database artefacts are cloned.

The users of the bridge subsystem that runs on the source release do not see the updated database artifacts,
which are prepared for the target release when the objects are cloned. However, SAP HANA repository 1.0 does
not provide the functionality to ensure the isolation of the source and target release.

To prepare an SAP S/4HANA system for updates with ZDO, all objects stored in _SYS_BIC must be migrated
to new containers based on the HTA for HDI technology (SAP HANA Transport for ABAP (HTA) for SAP HANA
Deployment Infrastructure (HDI)).

To prepare an SAP S/4HANA system for updates with ZDO, all objects stored in _SYS_BIC must be migrated
to new containers that are based on HTA for HDI technology. HTA for HDI means SAP HANA Transport
for ABAP (HTA) for SAP HANA Deployment Infrastructure (HDI). For more information, see the HTA for HDI
documentation on the SAP Help Portal.

 Note

All objects stored in SAP HANA repository 1.0 (_SYS_BIC) are not accessible during the runtime of the
bridge subsystem.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 49
The following figure shows a typical SAP S/4HANA database architecture:

Note the following information about the mandatory migration of following listed objects to HDI containers:

• All objects stored in _SYS_BIC and used by business processes:

Applications such as SAP BPC and SAP Real-Time Consolidation have provided migration reports. For
these application-specific migration reports, see the following SAP Notes:
• SAP Business Planning and Consolidation: SAP Note 2649528
• SAP Real-Time Consolidation: SAP Note 2643245
• SAP Customer Activity Repository: SAP Notes 2948917 and 2981564
• All custom objects that are used by business processes:
Use the SAP HANA XS Advanced Migration Assistant for the migration of customer objects. For more
information, see the SAP HANA XS Advanced Migration Guide .
See the following tutorial for the correct naming of the native SAP HANA objects: Tutorial: Developing and
Consuming HDI Objects in ABAP

4.14 Backup Strategy for ZDO

This section deals with aspects of the data backup in the ZDO procedure.

During a ZDO update, the users continue to work until the end of the maintenance event. They have to log off
from the system only for the time of the cutover.

During the uptime processing, database logging is kept active, and if scheduled, regular system backups are
triggered in the background. Before the cutover is started, it is recommended to perform a full system backup
that includes:

• a synchronous state of the database

• the SUM directory
• the system and instance directories
• the kernel directory

After a major problem occurs after a switch over to the new release, you can restore the system to the state of
the full system backup. Then, a reset of the SUM procedure could be performed as described in Resetting the
ZDO Procedure [page 59].

Zero Downtime Option for SAP S/4HANA

50 PUBLIC Preparation
You are asked in a dialog in phase SUMASK_ZDO_CONFIGURATION of roadmap step Configuration whether
you want to run a system backup during the transition from the bridge subsystem to the target subsystem.

If you choose this option, a further dialog in phase REQ_ZDO_SYSTEM_BACKUP of roadmap step Postprocessing
prompts you to start the system backup. If you confirm, the bridge subsystem stops, and you can start to
perform a full system backup.

To reset the update from this point in time, back up now the complete SUM directory including all
subdirectories! In addition, the current state of the database, the system and instance directories, and the
kernel directory must be backed up to be able to restore to a consistent state.

Zero Downtime Option for SAP S/4HANA

Preparation PUBLIC 51
5 Running the Software Update Manager

This part of the document contains information about the update procedure using the ZDO of SUM.

1. Roadmap Steps with ZDO Features [page 52]

2. Resetting the ZDO Procedure [page 59]
3. Special Features for ZDO [page 59]

5.1 Roadmap Steps with ZDO Features

This section describes ZDO-specific actions during the different roadmap steps of a SUM procedure.

The following roadmap steps are affected:

• Get Roadmap: Enabling ZDO During the Initial Dialogs [page 52]
• Configuration [page 53]
• Execution [page 54]
• Checks [page 54]
• Postprocessing [page 58]

5.1.1 Get Roadmap: Enabling ZDO During the Initial Dialogs

If you are eligible to use the Zero Downtime Option, you can select the option in the initial dialogs of SUM.

Context

For more information about the initial dialogs, see in the SUM Guide the following chapters:

• Planning Initial Dialogs for the Scenario Specification (Get Roadmap)

• Running the Software Update Manager Actions During the Roadmap Steps Specifying the Scenario
to Get the Roadmap Making Entries for Scenarios with Configuration File

Zero Downtime Option for SAP S/4HANA

52 PUBLIC Running the Software Update Manager
To enable the ZDO feature, proceed as follows:

Procedure

1. During the specification of the scenario strategy in phase MOD_SELROADMAP/SELECT_ROADMAP, you

select first the strategy Downtime-optimized and here the ZDO feature. Then choose Next.
2. In a subsequent dialog, you are asked to report an incident to get a password that authorizes you to use the
ZDO feature.
3. After you have received the password, enter it in the dialog and choose Next.

5.1.2 Configuration

The section deals with ZDO-specific activities in the Configuration roadmap step of the Software Update
Manager.

Parameter Setting for the Procedure

To configure the procedure, you can adapt the number of your uptime and downtime processes as well as your
SGEN processes.

Possibility of a System Backup

A dialog asks you in phase SUMASK_ZDO_CONFIGURATION whether you want to run a system backup during
the transition from the bridge subsystem to the target subsystem. If you choose this option, a further dialog in
phase REQ_ZDO_SYSTEM_BACKUP of roadmap step Postprocessing prompts you to start the system backup.

For more information, see Backup Strategy for ZDO [page 50].

RUN_ZDO_SLT_IMPANA_CONSISTENCY

This phase includes a check if there is a discrepancy in the number of SLT triggers in file ZDIMPANA.ZIP
provided for the Impact Analysis [page 23] and in the current SAP system.

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 53
5.1.3 Checks

The section deals with ZDO-specific activities in the Checks roadmap step of the Software Update Manager.

Phase Check

RUN_RSPTBFIL_ZDM_CHECK_BW This phase includes a check for an active SAP Business

Warehouse (SAP BW).

RUN_ZDO_CONSISTENCY_CHECK_* In this phase, the ZDO Consistency Check for ABAP diction-
ary objects and SLT setup is performed.

SUMCHK_ZDO_HTA_HTC This phase includes a check for SAP HANA repository ob-
jects, as these objects cannot be used during the SUM pro-
cedure with ZDO.

For more information, see Specific Phases for ZDO [page 14].

5.1.4 Preprocessing

The section deals with ZDO-specific activities in the Preprocessing roadmap step of the Software Update
Manager.

In phase RUN_IMPACT_ANALYSIS_ZDO, the Software Update Manager reads these table statistics and checks
the tables for conflicts. It stops with errors if critical conflicts are found, or if the table statistics file
ZDIMPANA.ZIP has not been provided.

For more information, see Impact Analysis Usage [page 27].

5.1.5 Execution

This section deals with ZDO-specific activities in the Execution roadmap step of the Software Update
Manager.

• Start of User Roll-Over to Bridge Subsystem [page 55]

• Monitoring the Reconnection of Work Processes [page 56]
• Monitoring the Change Recording and Replay Phases [page 56]

Zero Downtime Option for SAP S/4HANA

54 PUBLIC Running the Software Update Manager
5.1.5.1 Start of User Roll-Over to Bridge Subsystem

This section deals with the transition of the users to the bridge subsystem.

Start of User Roll-Over to Bridge Subsystem

The transition of the users to the bridge subsystem in phase MAIN_BRITRANS/REQ_USER_ROLLOVER_PREP

starts and rolls all users and work processes over to the bridge subsystem.

If the system is configured for a connection to the database using the Secure User Store (hdbuserstore),
make sure that all application servers instances have access to the shared hdbuserstore.

If the hdbuserstore is stored on a local file system, perform one of the following options:

• Option 1:
On the remote ABAP hosts, manually create hdbuserstore for the shadow system connection using the
following command:
hdbuserstore SET UPGSHDKEY <ENV> <USERNAME>SHD <PASSWORD> <ENV>

 Note

• Replace <ENV> and <USERNAME> with the values from hdbuserstore list.
• Replace <PASSWORD> with the password for the shadow database user (ABAP SHADOW DB USER
PASSWORD) that you have set in phase PREP_INSTALL/INITSHD.

• Option 2:
Switch your database connection to the ABAP Secure Store (SSFS).

 Note

Make sure to back up the HTC content of tables in the SAP HANA repository 1.0 after
REQ_USER_ROLLOVER_FINAL is successfully completed. For more on this backup, see Migration of Native
SAP HANA Database Objects [page 49] and SAP Note 2642660 as well.

Completion of User Roll-Over to Bridge Subsystem

The transition of the users to the bridge subsystem is completed in phase MAIN_BRITRANS/
REQ_USER_ROLLOVER_FINAL. Confirm the dialog by choosing Next. The update activities can be started.

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 55
5.1.5.2 Monitoring the Reconnection of Work Processes

This section deals with monitoring the reconnection of the work processes.

Context

In phase MAIN_BRITRANS/BRIDGE_RECONNECT, the Application Server ABAP (AS ABAP) work processes are
reconnected from the original database schema to the database schema of the bridge subsystem. However,
the work processes cannot be reconnected until they have completed the current unit of work.

To identify the work processes that have completed the reconnection, do the following:

Procedure

1. Call transaction SM66 in your SAP system.

2. Choose the icon Change Layout.
3. From the Column Set box, select Database Reconnect Status and drag it to the Displayed Columns box.
4. Choose Apply.

As a result, the Database Reconnect Status column of each work process is displayed as an additional
column in the work process overview.

If the reconnection exceeds your planned update schedule, you can force it manually. However, this can
cause the termination of long-running batch jobs that prevented the work processes from reconnecting.

To force the reconnection, open the Process Control Center in the More menu item SUM Utilities (Extended
UI). Select the row with the process name FORCE_RECONNECT and choose Start.

For more information on the Process Control Center, see in the SUM Guide the chapter Introduction
The Software Update Manager SUM Utilities (Extended UI) .

5.1.5.3 Monitoring the Change Recording and Replay

Phases

Context

You can monitor the replay phases and the replay progress of your update or upgrade with ZDO.

Zero Downtime Option for SAP S/4HANA

56 PUBLIC Running the Software Update Manager
Procedure

For monitoring, call transaction CRR_CONTROL.

 Note

If phase RUN_ZDOREPLAY_REPLAY_LKPM runs longer than expected, you can monitor the replay progress
using transaction CRR_CONTROL in the upgrade subsystem.

5.1.5.4 Unlocking the SAP System

This section deals with the option to unlock the SAP system during the ZDO procedure.

Context

The submodule unlockupg allows you to unlock the development environment of the upgrade system during
the ZDO procedure. The unlock enables you to perform necessary actions such as implementing SAP Notes or
making corrections.

The Software Update Manager runs this submodule only when a phase is repeated. This can happen when a
breakpoint has been set for it, or if an issue occurs during the phase, and the Software Update Manager offers
then the Repeat button.

In a subsequent dialog box, you can decide

• to start the phase

• to accept the errors and repeat the phase
• to unlock the upgrade system

Procedure

1. In the dialog Repeat Phase, select the option Unlock upgrade system.
A subsequent dialog informs you that the upgrade system and the development environment are now
unlocked. Before you start making changes, you must manually unlock the remaining locks in the
development environment. Make also sure that in the client administration, which you can open with
transaction SSC4, the option Changes to the repository and cross-client customizing allowed is selected for
the client. After that, you can perform the necessary actions.
2. When you have performed the actions, select the checkbox The necessary actions have been performed,
continue the SUM procedure in the current dialog Upgrade System and Development Environment are
Unlocked.

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 57
  Note

Only when you have confirmed that the actions have been performed, the Next button is active and you
can proceed with the ZDO procedure.

5.1.6 Postprocessing

This section deals with ZDO-specific activities in the Postprocessing roadmap step of the Software Update
Manager.

Preparation of User Roll-Back to Original System

In phase MAIN_BRITRANS/REQ_USER_ROLLBACK_PREP, users are transferred from the bridge subsystem (V1)
back to the production system (V2). All users must log off from the bridge subsystem.

Confirm the dialog in SUM by choosing Next.

 Note

• For a kernel update on remote instances, especially the ASCS instance, you must manually put the new
kernel in the replication directory. The kernel is distributed automatically after the production system is
restarted.
• On remote Windows hosts, you must need to install the Microsoft Visual C++ runtime environment
(vcredist_*.msi or .exe package) that is delivered with the new SAP kernel.
• Before you shut down the system, perform the steps described in SAP Note 2050677 .

Request for System Backup

If you have chosen in phase SUMASK_ZDO_CONFIGURATION of roadmap step Configuration that you want to
run a system backup during the transition from the bridge subsystem to the target subsystem, a dialog in
phase REQ_ZDO_SYSTEM_BACKUP prompts you to start the system backup.

For more information, see Backup Strategy for ZDO [page 50].

Completion of User Rollback to the Original System

The update procedure is complete. All users can log on again to the original productive system. In phase
REQ_USER_ROLLBACK_FINAL confirm the dialog in SUM by choosing Next.

Zero Downtime Option for SAP S/4HANA

58 PUBLIC Running the Software Update Manager
5.2 Special Features for ZDO

This section describes special features for the ZDO:

1. Restoring Table Content in the SAP HANA Repository 1.0 [page 60]
2. Final Validation [page 61]
3. Bridge and Update Subsystems During the Update [page 61]
4. Transition of Users to Bridge Subsystem [page 61]
5. Database Reconnect Transition Method [page 62]
6. Locks on the Bridge Subsystem [page 63]
7. Handling Problems with Specific Table Changes [page 63]

5.2.1 Resetting the ZDO Procedure

During the update with ZDO, you have a reset option provided that the cutover has not been performed.

Prerequisites

Make sure that phase REQ_ZDO_SYSTEM_BACKUP has not yet been passed.

Context

As long as the users were not rolled over to the bridge subsystem and the phase REQ_USER_ROLLOVER_PREP
has not been passed, you can perform a reset during uptime processing as in the standard update procedure.

For more information, see in the SUM Guide the chapter Running the Software Update Manager Working
with the SUM Tool Resetting the Update .

However, if the user rollover to the bridge subsystem has already been performed and the phase
REQ_USER_ROLLOVER_PREP is completed, the reset works in a two-step approach. If a system backup
is performed (see also Backup Strategy for ZDO [page 50]), the reset function is available until phase
REQ_ZDO_SYSTEM_BACKUP.

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 59
To reset the procedure, proceed as follows. After finishing both steps, you can start another update using
Software Update Manager.

 Note

• Reset Conditions
The reset procedure for ZDO can be executed completely in the uptime if the following conditions are
met:
• Source release SAP Basis 755 or higher. This release corresponds to SAP S/4HANA 2020 or
higher.
• SAP kernel 781 or a higher version. See the prerequisites for the SAP kernel used in SAP Note
3215062 . For more information about the SAP Kernel conditions, see also SAP Note 3169721 .
Otherwise, step 2 of the following procedure requires downtime because the bridge subsystem is
stopped and deleted. You can push this downtime to the next regular downtime window according to
your maintenance plan.

Procedure

1. In the More menu, choose Reset and confirm the Resetting Procedure dialog with Yes.

The reset procedure removes all read-only restrictions for the bridge subsystem during uptime. After this
removal, all read-only tables are writable again and users can continue with regular production operation.
2. When you continue with the reset procedure, the bridge subsystem is stopped and deleted.

5.2.2 Restoring Table Content in the SAP HANA Repository

1.0

This section deals with the option to restore table content in the SAP HANA repository 1.0.

Context

The ZDO of SUM offers the option to reset native SAP HANA database objects. After the reset, you must
restore your SAP HANA Transport Container (HTC) content, to import from the specified folder the content of
all database tables of the _SYS_BIC schema.

Zero Downtime Option for SAP S/4HANA

60 PUBLIC Running the Software Update Manager
Proceed as follows:

Procedure

1. Open the SAP HANA Studio and log in with the SYSTEM user to the system on the database and the tenant
where you want to import the table data.
2. Open the SQL console in the database schema _SYS_BIC.
3. To get the list of all table names, enter the following statement:

select TABLE_NAME from tables where SCHEMA_NAME='_SYS_BIC' and

is_user_defined_type='FALSE';
4. For each table, truncate the data before importing the old data by entering the following command:
truncate table <table_name>;
5. For each table, import the data from the location where you have previously saved the data of this table by
entering the following command:

import <table_name> from '<folder_name>' with data only;

5.2.3 Final Validation

Perform a final validation. Check custom development activities and third-party applications by scans and test
runs.

5.2.4 Bridge and Update Subsystems During the Update

During the update procedure, two subsystems exist in parallel: the bridge and the update subsystem.

The bridge subsystem and the update subsystem are subsystems of the production system, each with its own
database schema.

Both subsystems share several services. However, only the batch jobs and transactions running in the bridge
subsystem are assigned to the production instances.

5.2.5 Transition of Users to Bridge Subsystem

Before the update can be started on the update subsystem, all users must be disconnected from the original
production system and transferred to the bridge subsystem.

The transfer from the production system to the bridge subsystem runs smoothly at database connection level.
This process runs unnoticed by the users.

The bridge subsystem is a separate subsystem in the context of the production system. Once all users are
transferred to the bridge subsystem after the MAIN_BRITRANS/REQ_USER_ROLLOVER_FINAL phase, the

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 61
repository tables as well as other tables that need to be accessed by the update are renamed. The bridge
subsystem retains access to the renamed tables.

After the update has finished, all activities that were started on the bridge subsystem must be completed. All
users are logged off the bridge subsystem and all activities are shut down. The users are then logged on to the
production system again.

 Note

Always keep these steps in mind to avoid prolonged cool-down time.

5.2.6 Database Reconnect Transition Method

The section deals with the transition method for the database reconnect (DB reconnect)

The ZDO of SUM enables an update in parallel to the user activities in the SAP system. The aim is to ensure

1. a smooth transfer of users from the productive system to the bridge subsystem
2. their reconnection to the bridge subsystem without downtime

Typically, an SAP application server collects requests from multiple front ends and dispatches them to the work
processes that execute the requests, such as a specific ABAP program. Several dialog work processes run on
one application server.

The transition of the dialog and batch work processes to the bridge subsystem requires a database connection
to the database schema on the bridge subsystem. For the transition, the production system and the bridge
subsystem must have the same start release and the same table content in the database schemas.

 Note

Make sure that all SAP application servers are running with the same kernel version.

The advantages of this method are:

• No system downtime
• Automated procedure
• No logout and logon of users required
• Transparent for administrators
• Automated workload roll-over

The database connection must be changed for all users who are connected to the database schema of the
bridge subsystem.

When the transition is started, any work process that becomes free to be scheduled for a new logon or a newly
started batch job was previously idle. Such a work process is either already in the bridge database schema,
or it used the idle time to perform the DB reconnect. The effect is that every new logged-in user and each
newly started batch job are automatically in a work process on the bridge subsystem. The idled work processes
are reconnected immediately. SUM checks the status of the Task Handler whether all tasks of the work
processes are reconnected and then continues with the update procedure.

Users who are in a session without calling a COMMIT WORK are logged off when the timeout is reached. The
timeout is controlled by a parameter.

Zero Downtime Option for SAP S/4HANA

62 PUBLIC Running the Software Update Manager
If no COMMIT is set, a default value defines the maximum number of seconds for the abort case.

You can monitor the reconnect status as described in Monitoring the Reconnection of Work Processes [page
56].

5.2.7 Locks on the Bridge Subsystem

This section is about the locks on the bridge subsystem.

During the update procedure, the bridge subsystem communicates with the tables that are affected by the
update. To avoid collisions between the update and the users who work on the bridge subsystem, locks are
implemented on the bridge subsystem. These locks can be set by the following processes:

Process Comment

Table conversion At the beginning of the update, affected tables become read-
only to prevent them from being modified.

After-import methods (AIM) At the end of the update, affected tables are locked to pre-
vent them from being modified. In this case, you receive an
error message with the user usr_persist.

The following locks are implemented in addition:

Lock Comment

EU_LOCK At the beginning of the update, a generic lock is set for af-
fected tables and applications.

Client locks At the beginning of the update, after-import methods (AIM)

lock tables that are affected by the update. These tables
remain locked until the update is completed.

 Caution

If you try to access read-only tables, for example by executing transactions or reports, you receive a
runtime error. This is to avoid inconsistencies.

5.2.8 Handling Problems with Specific Table Changes

During a system update or upgrade, changes to tables can lead to data loss, for example, when key fields
are deleted or field lengths are reduced. If data in the tables cannot be converted to the new table structure,
the procedure stops with an error message in phase PARCONV_UPG. The table data must then be corrected
manually, and the tables are set into read-only mode during the bridge phase.

Tables that are to be processed with the following structural changes:

Zero Downtime Option for SAP S/4HANA

Running the Software Update Manager PUBLIC 63
• Field length reduction and decimal changes for DEC fields
• Field length reduction for CHAR fields

are not set to read-only mode but added to the file ZDM_FIELD_SHORTENING.LST. This file is located in the
var subdirectory of the SUM directory.

Then, the above-mentioned structural changes are made to the tables during the following ZDO procedure.
However, issues can occur in the following phases:

Phase Issue Solution

SQLRUNTASK_FDCT_TRANSFER In this phase, the initial data transfer Correct the table data manually in the
of all cloned tables is performed. If the table of the source release. (Note that
table data cannot be converted to the the table name at database level begins
new table structure, the phase stops with TAB~~.)
with a Numeric Overflow error fol-
lowing by the information that the value
cannot be converted.

RUN_ZDOREPLAY_REPLAY_LKPM If after the initial data transfer a record Correct the table data manually in the
is written that does not fit into the re- table of the source release. (Note that
duced data field, this phase stops with the table name at database level begins
the following error message: with TAB~~.)

Unable to MODIFY target

table <TAB> due to SQL
code 314.

After phase After the replay phases, the SLT trigger

RUN_ZDOREPLAY_REPLAY_LKPM tries at database level to insert the data
directly into the table of the target re-
lease. The following error can occur in
the bridge instance:

SQL error "SQL code: 314"

occurred while accessing
table <table name>

 Note

If you do not want this specific table handling, you can disable it by adding the following parameter to the
file sapup_add.par: SKIP_FIELD_SHORTENING=YES

The affected tables are then set into read-only mode as usual.

If data is already existing and the parameter SKIP_FIELD_SHORTENING has the value NO, you must adjust
the data in phase PARCONV_UPG nonetheless.

Note that the file SAPup_add.par is located in the subdirectory bin of the SUM directory. If this file does
not exist yet, create it manually.

Zero Downtime Option for SAP S/4HANA

64 PUBLIC Running the Software Update Manager
6 Follow-Up Activities

This part of the document contains information about the follow-up activities that you need to perform after
you've updated your SAP system with ZDO of SUM.

You can already start the following follow-up activities when the SUM has reached the phase MAIN_POSTPROC/
SUBMOD_BRIDGE_POSTPROC/REQ_USER_ROLLBACK_FINAL:

• Reactivate the batch job for UPL data collection. For more information, see Handling UPL Data Collection
Job [page 37].
• Reactivate BW extractors. For more information, see SAP Business Warehouse Extractor Handling [page
38].

In addition to the follow-up activities specific to the update with ZDO of SUM, consider also the follow-up
activities that are described in the SUM Guide.

Zero Downtime Option for SAP S/4HANA

Follow-Up Activities PUBLIC 65
7 Troubleshooting

This section provides additional information about how to proceed with general troubleshooting or how to
resolve known issues that occurred during the update.

1. General Troubleshooting Activities [page 66]

2. Known Issues [page 67]

7.1 General Troubleshooting Activities

This section deals with general activities to perform a successful troubleshooting.

Consider the following troubleshooting activities:

• Check the relevant log files [page 66]

• Analyze short dumps [page 66]
• Check the background job overview [page 67]

For additional known issues and their solution, see SAP Note 2707753 .

Checking the Relevant Log Files

As a first step in a problem, we recommend that you look at the SUM user interface. In many cases, an excerpt
from a log file is displayed here, which is a good starting point for error analysis. Additional log files are available
in the abap log subdirectory of the SUM Directory. Call up the list of log files and sort the display in
descending order by time. Check the most recent files first, as SUM updates the log files frequently. In some
cases, checking the most recent log files in the subdirectory abap tmp is also useful.

Analyzing Short Dumps

The analysis of short dumps can help to correct errors in the ABAP system. Use the ABAP Dump Analysis
(transaction ST22), which you can use to list the short dumps that occurred in the ABAP system.

If the cause of a short dump is unclear or if you cannot correct the error yourself, report an incident for the
application component listed in the header line of the short dump list.

Zero Downtime Option for SAP S/4HANA

66 PUBLIC Troubleshooting
Checking the Background Job Overview

Using transaction SM37, you can monitor jobs running in your SAP system and find information about aborted
jobs. To check for aborted jobs, enter the following in the dialog Simple Job Selection:

Job Name *

User Name DDIC or *

Job Status Choose Canceled

Job Start Condition Enter a relevant timeframe.

Example: Enter the current date in From and To to get all

aborted jobs of the current day.

7.2 Known Issues

This part of the document contains additional information on how to proceed when you want to correct known
problems during the ZDO procedure.

If a problem is not listed here, or if you need additional assistance, report an incident on component BC-
UPG-DTM-TLA. Use the following convention for the short description: [ZDO of SUM] - <Issue short
description>

The following issues are known:

• Running SUM with ZDO After a Previous Run Has Been Reset [page 68]
• Reset: Error in Phase RUN_RSDB02CK_REV [page 68]
• Cleaning up the Orphaned Update Records [page 69]
• Error in File LONGPOST.Log [page 69]
• Error in Phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP [page 70]
• Error in Phase MAIN_NEWBAS/XPRAS_AIMMRG [page 70]
• Remaining Views After Reset of a ZDO Update to SAP S/4HANA 2020 [page 71]
• Performance of Phase SQLRUNTASK_FDCT_TRANSFER on SAP HANA DATABASE [page 71]
• During Reset System Separation Between Bridge System and Upgrade System Isn't Correctly Reset [page
72]
• Error in PARRUN_ZDO_CONSISTENCY_CHECK or RUN_ZDO_CONSISTENCY_CHECK_POST [page 73]
• Error in Phase RUN_RSPTBFIL_ZDM_CHECK_BW [page 74]
• Error in Phase RUN_ZDO_SLT_IMPANA_CONSISTENCY [page 75]
• Serialization Error in Phases Starting with the Name Prefix SCEXEC_GRANT_* [page 76]

Zero Downtime Option for SAP S/4HANA

Troubleshooting PUBLIC 67
Running SUM with ZDO After a Previous Run Has Been Reset

Symptom Solution

During the reset of a ZDO update, newly added database Make sure in transaction DB02 that there are no additional
tables are not dropped. database tables that belong to SAP.

Reset: Error in Phase RUN_RSDB02CK_REV

Symptom Solution

One of the following tables does not exist in the database: Create the tables manually in the database using transaction
SE14. Afterwards repeat the phase.
TEST_POOL1
VER_SEC_INDX
VER_SEC_TAB1
CRR_CHCNC
CRR_CHCWC
CRR_CHENC
CRR_CHEWC
CRR_CHLNC
CRR_CHLWC
CRR_CHSNC
CRR_CHSWC
CRR_CH_LOCK
CRR_CH_SI
CRR_CSCWC
CRR_CT1P
CRR_CT1S1
CRR_CT1S2
CRR_CT1S3
CRR_CT2P
CRR_CT2S1
CRR_CT2S2
CRR_CT3P
CRR_CT3S1
CRR_CT3S2

Zero Downtime Option for SAP S/4HANA

68 PUBLIC Troubleshooting
Cleaning up the Orphaned Update Records

Symptom Solution

SUM stops in phase MAIN_NEWBAS/RUN_UPDATE_CHECK 1. Call transaction SM13 on the bridge subsystem and en-
with the following error message: ter date and time of the error message. A list of all
update records is displayed.
A2EESZDM 669 Record in VBHDR found
for update: key "<UPDATE KEY>" report 2. Using the menu item Settings Layout

"<REPORT>" state "2" date <TIME STAMP> Current... , add the additional column name Update
Key to the displayed columns of the update records
table.
3. Filter the list by the update key from the error message.
4. Clean up the update records found by the filter condi-
tion.

Error in File LONGPOST.Log

Symptom Solution

You see the following error in log file Longpost.log: You can ignore this error because it is a generated CDS view
that was additionally handled during the update in the XPRA
### CURRENT PHASE: RUN_RSUPGDDLSCREATE
phase.
1PEPU203X--> Messages extracted from log The view should therefore exist in the database and no fur-
file "RSUPGDDLSCREATE.Y20" <-- ther action is required.

A4PEDDUT 368 Create statement view

"ACMAUTE639F7F4D8" could not be
generated

Zero Downtime Option for SAP S/4HANA

Troubleshooting PUBLIC 69
Error in Phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP

Symptom Solution

The phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP fails Execute transaction SM37 in client 000. Select as follows:
with an error message similar to:
• Job Name: RDDIMPDP
2EEDA480 Update fails (mode flag "D" to
"X" in DDXTT. Table: "<TABNAME>")
• User Name: *
• Job Status: Released
The reason is that a new instance of batch job
• Or after event: SAP_TRIGGER_RDDIMPDP
RDDIMPDP was scheduled for the upgrade subsystem
in phase MAIN_NEWBAS/JOB_RDDNEWPP. After switching Multiple instances of the RDDIMPDP batch job must not be
off the subsystem isolation in phase MAIN_POSTPROC/ displayed. Delete them all.
SUBMOD_BRIDGE_POSTPROC/RUN_RLFW_SYSTEMSEP_OFF,
Then schedule a new instance of the batch job RDDIMPDP.
this additional instance of batch job RDDIMPDP becomes ac-
Use the RDDNEWPP program for this, as described in SAP
tive on the target system. This is not supported.
Note 34964 .

Then repeat the phase.

Error in Phase MAIN_NEWBAS/XPRAS_AIMMRG

Symptom Solution

You see in phase XPRAS_AIMMRG the following error mes- See SAP Note 1649901 .
sage:

[...]

A2EERSAR 203 Source system

"<LOGSYSNAME>" does not exist

2EESY530 An exception was raised

A2 ERSBK 034 Generate D versions

from "DTP_7MODTUOAGKW6IILPKSNI78RCH"
("R/3730" -> "<LOGSYSNAME>")

A2EERS_EXCEPTION 120 Operation

&3"0TCTTABCAT_TEXT

<LOGSYSNAME>get_access" could not

be carried out for &1"DTPA"
&2"DTP_46MRIQEWUMPPSW8YXAMKD4JMZ"

[...]

Zero Downtime Option for SAP S/4HANA

70 PUBLIC Troubleshooting
Remaining Views After Reset of a ZDO Update to SAP S/4HANA 2020

Symptom Solution

After a reset, there are still database views that should have Check with the following select statement the existence
been deleted. of the views in the database:

select tabname from puttb_shd

where srctype = 'B' and

srcform = 'T' and

dsttype = 'W' and

dstform = 'T'.

If affected views still exist in the database, drop them man-

ually.

Performance of Phase SQLRUNTASK_FDCT_TRANSFER on SAP HANA

DATABASE

Symptom Solution

The Fast Data Copy transfer, which is executed in the phase Add to file SAPup_add.par the following line to increase
SQLRUNTASK_FDCT_TRANSFER, has an impact on the per- the number of DDL processes:
formance of the SAP HANA database. Especially, the I/O
/SQLRUNTASK_FDCT_TRANSFER/HDB/parprocs/DDL =
performance of a production system must be monitored
<numer of parallel processes>
during the execution of this phase.
The file SAPup_add.par is located in the subdirectory
See SAP Note 1999993 for more information on a health
bin of the SUM directory. If this file does not exist yet,
check of your SAP HANA database. It describes how to use
create it.
and interpret the results of the SAP HANA mini checks.
Note: Consider also the load on the productive system dur-
To ensure a stable and consistent data copy, SUM sets the
ing this analysis. Setting the number of DDL processes to a
number of processes for the execution of the SQL state-
higher value can lead to a massive impact on the productive
ments of phase SQLRUNTASK_FDCT_TRANSFER by default to
system and a significant database slowdown.
2.

You can increase the number of parallel DDL processes if

• you have business requirements to minimize the run-

time of phase SQLRUNTASK_FDCT_TRANSFER
• a performance analysis SAP HANA database of the pro-
ductive system shows that more parallel processes can
be used without affecting the performance and stability
of the SAP HANA database

Zero Downtime Option for SAP S/4HANA

Troubleshooting PUBLIC 71
During Reset System Separation Between Bridge System and Upgrade
System Isn't Correctly Reset

Symptom Solution

During the reset, the system separation between bridge sub- Delete the RFC connection SAP_UPGRADE_UPG_SYSTEM us-
system and upgrade subsystem is not reset correctly. This ing transaction SM59.
can cause problems, such as scheduled background jobs
Then execute program RLFW_SYSTEM_SEPARATION in
that are not recognized correctly by the system and there-
transaction SE38. Use the parameter p_action =
fore are not triggered as expected.
DEACTIVATE and logfile = RLFW_SYSTEMSEP_OFF.
For example: A transport is to be imported into the system
and seems to hang after the DDIC import. In the SLOG*, you
see messages such as:

ERROR: Background job RDDIMPDP could not

be started or terminated

ERROR: Please check that the R/3 system

is running.

ERROR: Please check the system. Use

transactions SM21, SM37, SM50..

Zero Downtime Option for SAP S/4HANA

72 PUBLIC Troubleshooting
Error in PARRUN_ZDO_CONSISTENCY_CHECK or
RUN_ZDO_CONSISTENCY_CHECK_POST

With Regard To The SLT Setup

Symptom Solution

You are using an SLT server setup. SUM 1. Check if the table is part of SLT replication.
stops in phase PARRUN_ZDO_CONSISTENCY_CHECK or 2. If so, check the connection of the SLT setup: Is the SLT
RUN_ZDO_CONSISTENCY_CHECK_POST with one of the fol- replication done using an RFC connection or a second
lowing two error messages: database connection?
3. Possible solutions are:
A2EESUPG 763 Table <table> has no SLT
1. If the table is not part of the SLT replication, delete
triggers, but has an SLT logging table
the SLT triggers and the found logging table. Then
<logging table>
repeat the phase.
A2EESUPG 764 Table <table> has no SLT 2. If the table is part of the SLT replication based on
logging table in DDIC, but has an SLT an RFC connection, regenerate the missing SLT ob-
trigger <SLT trigger> jects.
3. If the table is part of SLT replication based on
a second database connection, the Software Up-
date Manager does not support SLT handling in
the bridge subsystem. In this case, we recommend
changing the connection to an RFC-based connec-
tion.
Alternatively, reset SUM, restart the procedure
from the beginning and deactivate the SLT han-
dling in phase SUMASK_RFC_2_SLT_SERVER.

With Regard To ABAP Dictionary Objects

Symptom Solution

The ZDO consistency check detects that ABAP Dictionary Resolve the inconsistencies using the ABAP Dictionary tools
objects are inconsistent. The system displays error mes- provided with the transactions SE11 and SE14. If you can-
sages such as: not resolve the inconsistencies, report an incident on com-
ponent BC-UPG-DTM-TLA.
A2EESUPG 642 Index "XYZ" of table
"TABLE1" does not exist in DDIC(DB-Idx
Name:"TABLE1~YXZ")

A2EESUPG 234 Table "TABLE2" is

inconsistent in key information NT <->
DB

A2EESUPG 007 Unable to determine

the table delta between "TABLE3" and
"TABLE3"

Zero Downtime Option for SAP S/4HANA

Troubleshooting PUBLIC 73
Error in Phase RUN_RSPTBFIL_ZDM_CHECK_BW

Symptom Solution

SUM stops in phase RUN_RSPTBFIL_ZDM_CHECK_BW with The ZDO of SUM does not support the DATA_WAREHOUSE
following error message: scope of SAP BW. During the analysis, you must find out why
the SAP BW objects are active in the system and whether
A2EESZDM_SRC 074 System scope is
they are used at all. We recommend the following procedure:
DATA_WAREHOUSE, ZDO is not supported,
see SAP note 2707731 1. Clarify with your functional teams which business ap-
plications are used in SAP S/4HANA and use the de-
Furthermore, the log file contains detailed information about termined SAP BW objects (Advanced Data Stores,
why the scope DATA_WAREHOUSING was determined. Exam- Data Stores, InfoCubes, or Persistent Staging
ple messages: Areas).
A4 ESZDM_SRC 070 Begin check for active 2. If the functional teams confirm that SAP BW objects are
BW. used by the business applications, the SUM procedure
A4 ESUPG2 013 No allow file ZDO_BW_EX-
CEPTION.LST found for BW check with ZDO is not possible. If in doubt, report an incident
A4 ESUPG 003 Objectype: Advanced Data on the application component that uses the active SAP
Stores BW object.
A4 ESZDM_SRC 082 Advanced Data Stores:
0 found 3. You can skip the check if
A4 ESUPG 003 Objectype: Data Stores
A4 ESZDM_SRC 082 Data Stores: 0 found • you can confirm that SAP BW is not used by the
A4 ESUPG 003 Objectype: Info Cubes functional teams or the use of SAP BW can be re-
A2EESZDM_SRC 082 Info Cubes: 4 found stricted during the bridge phase
A2EESUPG 002 /CPD/CPFP_R01
A2EESUPG 002 /CPD/PFP_C01 • the check, however, has determined the active use
A2EESUPG 002 /CPD/PFP_R01 of data warehousing
A2EESUPG 002 /ERP/SFIN_R01
A4 ESUPG 003 Objectype: Persistent Stag- To accept unsupported SAP BW objects and continue
ing Areas the procedure, create the file ZDO_BW_ALLOW.LST
A4 ESZDM_SRC 082 Persistent Staging
Areas: 0 found and add it to the var subdirectory of the SUM Direc-
A4 ESUPG 003 Objectype: HANA-Composite tory. In the file, specify in the form of a simple list the
Provider SAP BW objects that can be ignored. Enter one object
A4 ESZDM_SRC 082 HANA-Composite Pro-
vider: 0 found name per line without separators as end-of-line repre-
A4 ESUPG 003 Objectype: Local Workspace sentation.
provider
A4 ESZDM_SRC 082 Local Workspace pro- 4. If you cannot restrict the usage of critical SAP BW ob-
vider: 0 found jects for the bridge phase, you can report an incident on
A4 ESUPG 003 Objectype: Characteristics component BC-UPG-DTM-TLA.
with transitive attributes
A4 ESZDM_SRC 082 Characteristics with
transitive attributes: 0 found
A4 ESUPG 003 Objectype: Characteristic
with external view
A4 ESZDM_SRC 082 Characteristics with
external view: 0 found
A4 ESUPG 003 Objectype: Open Opera-
tional DataStore
A4 ESZDM_SRC 082 Open Operational Data-
Store: 0 found
A4 ESUPG 003 Objectype: Non HDI Hana
Models
A2EESZDM_SRC 082 Non HDI Hana Models: 1
found
A2EESUPG 002 ZJSALESHV
A2EESZDM_SRC 074 System scope is
DATA_WAREHOUSE, ZDO is not supported,

Zero Downtime Option for SAP S/4HANA

74 PUBLIC Troubleshooting
Symptom Solution

see SAP Note 2707731

A4 ESZDM_SRC 075 For the complete list,
execute report RSUPG_CHECK_BW
A4 ESUPG 002
A4 ESZDM_SRC 071 End check for active BW

 Caution
The output of the log file RSZDM_CHK_BW.<SID>
written by the Software Update Manager can be incom-
plete because the number of lines per object type is
limited to 25. To get a complete object list, execute the
ZDO Preliminary Checks tool of the SUM Toolbox
and check the result of the SAP BW Check-ID for SAP
Business Warehouse.

Error in Phase RUN_ZDO_SLT_IMPANA_CONSISTENCY

Example of Error Messages Solution

A2EESZDM2 040 Table TESTTAB1 has SLT • If you want to test ZDO with SLT in the current SUM
triggers on current system, but not in procedure

ZDIMPANA.ZIP 1. Make sure that statistics file ZDIMPANA.ZIP

was exported from the correct production system.
A2EESZDM2 041 Table TESTTAB2 has SLT
If the wrong file is used, replace the file in your
triggers in ZDIMPANA.ZIP, but not on download directory with the correct one and repeat
current system the phase.

A2EESZDM2 024 Inconsistency with SLT 2. You can either ignore the errors, but all the tables

triggers between current system and mentioned can then have an incorrect impact anal-
ysis result. Or you reset the Software Update Man-
ZDIMPANA.ZIP
ager and set up SLT again accordingly. Then restart
the Software Update Manager.
• If you do not want to test ZDO with SLT in the current
SUM procedure:
1. Cleanup all SLT triggers in your current system.
2. Then ignore the errors and continue with the next
phase.

Zero Downtime Option for SAP S/4HANA

Troubleshooting PUBLIC 75
Serialization Error in Phases Starting with the Name Prefix
SCEXEC_GRANT_*

Symptom Solution

When running phases that start with the name prefix Add a line with the affected phase name to the
SCEXEC_GRANT_* (such as SCEXEC_GRANT_ALL), a seriali- SAPup_add.par file as follows:
zation error can occur with an error message similar to the
/<phase_name>/HDB/parprocs/DDL = 1
following:

3 ETQ400 Rows affected: 0 Example for phase SCEXEC_GRANT_ALL: /

3 ETQ398 SQL: GRANT ALL PRIVILEGES SCEXEC_GRANT_ALL/HDB/parprocs/DDL = 1
ON SAPHANADB."FDT_RLST_1200T~~" TO SA-
PHANADBSHD
3 ETQ400 Rows affected: 0  Note
3 ETQ398 SQL: GRANT ALL PRIVILEGES
ON SAPHANADB."FINSC_LD_CMP~~" TO SAPHA- The file SAPup_add.par is located in the subdirec-
NADBSHD tory bin of the SUM directory. If this file does not exist
4 ETQ010 Date & Time: 20220715124538
1EETQ008 Error message: DBSL error 99 yet, create it.
(db code 129):
1EETQ009Xtransaction rolled back by an
internal error: Serialization failure:
1EETQ009X[current tx] tx_oid=225,
tid=785828101 [latest version] TID:
785828823
1 ETP111 exit code : "20"

Zero Downtime Option for SAP S/4HANA

76 PUBLIC Troubleshooting
Important Disclaimers and Legal Information

Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:

• Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:

• The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.

• SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

• Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering an SAP-hosted Web site. By using
such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.

Videos Hosted on External Platforms

Some videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any
advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within
the control or responsibility of SAP.

Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Bias-Free Language
SAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities,
genders, and abilities.

Zero Downtime Option for SAP S/4HANA

Important Disclaimers and Legal Information PUBLIC 77
www.sap.com/contactsap

© 2024 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN