Zdo Sum20 S4hana

Upgrade Guide | PUBLIC
Software Update Manager 2.0 SP15

Document Version: 1.0 – 2022-10-10
Zero Downtime Option for SAP S/4HANA

© 2022 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Project Planning Aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Test Cycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Exemplary High-Level Project Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Additional Steps for ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Estimation of the Right Time for Rollover and Rollback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Impact Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Impact Analysis at a Glance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Exporting Table Statistics to the Productive System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Impact Analysis Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Applying Best Practice for Impact Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.3 Restrictions During the Runtime of the Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Hardware Requirements Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 High-Availability Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Add-On Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Handling UPL Data Collection Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 SAP Business Warehouse Extractor Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Silent Data Migration Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
4.7 SLT Replication Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
4.8 Usage of Custom Database Schemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Backing Up Table Content in the SAP HANA Repository 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
4.10 Migration of Native SAP HANA Database Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
4.11 Backup Strategy for ZDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2 PUBLIC Content
5 Running the Software Update Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 Roadmap Steps with ZDO Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Get Roadmap: Enabling ZDO During the Initial Dialogs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Preprocessing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Postprocessing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Resetting the ZDO Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
5.3 Special Features for ZDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Restoring Table Content in the SAP HANA Repository 1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Final Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Bridge and Update Subsystems During the Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Transition of Users to Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Database Reconnect Transition Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Locks on the Bridge Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Follow-Up Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.1 General Troubleshooting Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2 Known Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Content PUBLIC 3
Document History
Document: Zero Downtime Option of SUM 2.0 SP15 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 at http://support.sap.com/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 2022-10-10 Initial version

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 7]
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.

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
Trusted RFC not needed any The previously required preparation step to activate SUM 2.0 SP13
more the user DDIC for a trusted RFC connection from the
bridge system to the target system is no longer nec
essary. The chapter Activating the user DDIC for a
trusted RFC connection that existed in previous
guide versions has therefore been removed.
Simplification of SLT trigger han For SLT replication handling, the SLT trigger han SUM 2.0 SP13
dling dling has been simplified. In addition, some phase
names have been renamed. For more information,
see SLT Replication Handling [page 35].
ZDO Consistency Check en The ZDO Consistency Check now also checks and SUM 2.0 SP14
hanced validates the consistency of SLT scenarios. For more
information, see SLT Replication Handling [page
35].
Multiple SLT servers are sup For SAP HANA database, ZDO supports now multi SUM 2.0 SP14
ported ple SLT servers. For more information, see SLT Rep
lication Handling [page 35].

6 PUBLIC Before You Start
Feature Description Availability
High availability maintenance ZDO supports now the update of high availability SUM 2.0 SP14
mode is supported systems. A dialog in the phase
SUM_ASK_ZDO_CONFIGURATION asks you whether
you want to switch to HA maintenance mode for fur
ther execution. For more information, see High-
Availability Setup [page 32].
Supported add-ons The number of supported add-ons has been en SUM 2.0 SP14
hanced. For more information, see Add-On Handling
[page 32].
BW Check The documentation regarding BW Check and the SUM 2.0 SP15
phase RUN_RSPTBFIL_ZDM_CHECK_BW has been
updated. For more information, see Specific Phases
for ZDO [page 14].
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].
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 techni
cal perspective, the bridge database schema reuses the shadow da
tabase 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 dic
tionary objects of the target release in the shadow database
schema.

Before You Start PUBLIC 7
Term Description
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 al

lows 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 con
nected 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.
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.

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 system releases
• System release upgrades

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.

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.

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.

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 50]), all work processes are automatically reconnected to
the bridge schema in phase BRIDGE_RECONNECT (see also Database Reconnect Transition Method [page
51]).
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.

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

SUMASK_ZDO_CONFIGURATION backup needs to be performed during
the system restart.
For more information, see Backup

Strategy for ZDO [page 40]
RUN_RSPTBFIL_ZDM_CHECK_BW SAP BW Check Checks for an active SAP BW system.

As a result, 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
For more information, see Error
in Phase
RUN_RSPTBFIL_ZDM_CHECK_B
W [page 55].

PREP_GENCHECKS/ ZDO consistency check for ABAP dic The purpose of the check is to detect
PARRUN_ZDO_CONSISTENCY_* tionary objects, database objects, SLT inconsistencies already in the original
logging tables, and SLT triggers system at an early stage as part of the
General Checks module.
For example, ZDO can only handle data

base indexes that are defined in the
data dictionary. Undefined indexes dis
appear 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
55] the section Error in Phase

PARRUN_ZDO_CONSISTENCY_CHECK
or
RUN_ZDO_CONSISTENCY_CHECK_PO
ST With Regard To The SLT Setup .
MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Test import for ZDO Preparation step required for ZDO table
GENKEYTRACE classification.
MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Implementation of SAP Notes in the Checks for SAP Note corrections re
CHECK4NOTES_TOOL_SHD2 shadow system quired by SUM in the shadow system.
These SAP Notes belong to the target
release.
MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Table classification to calculate the han In phase

SUBMOD_LC4BRI_PREP/ dling of tables during the ZDO proce RUN_RSPTBFIL_ZDM_CLASSIFY, ta
RUN_RSPTBFIL_ZDM_CLASSIFY dure bles are classified as follows on how
they are handled during the upgrade.
• Share: Tables are not affected by

the upgrade
• Clone: Tables are populated with
new or additional content
• Read Only: Tables to which com
plex structural changes are made
A possible business impact can be esti

mated with the Impact Analysis [page
21].

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Impact analysis by SUM in batch mode Analysis of the table classification im
SUBMOD_LC4BRI_PREP/ pact on productive usage statistics re
RUN_IMPACT_ANALYSIS_ZDO garding tables that are modified by af
ter-import methods.
From this phase on, the dialog version

of the impact analysis can also be used.
For more information, see Impact Anal
ysis Usage [page 24].
Start phase: MAIN_BRISETUP/ Rollover to bridge subsystem From this point in time, tables classified
REQ_USER_ROLLOVER_PREP as Read Only become read-only for the
bridge subsystem.
Completed with phase:
MAIN_BRITRANS/
REQ_USER_ROLLOVER_FINAL
MAIN_SWITCH/EU_SWITCH_ZDM
Smart switch SUM renames the original tables classi
fied 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

RUN_ZDOREPLAY_REPLAY_LKPM the runtime of phase
SQLRUNTASK_FDCT_TRANSFER.
MAIN_POSTPROC/ Illegal access check Checks for illegal table access from the
SUBMOD_BRIDGE_POSTPROC/ upgrade subsystem.
RUN_PREP_CHECK_ILLACCESS
Start phase: MAIN_POSTPROC/ End of bridge subsystem Roll back to the productive system and
SUBMOD_BRIDGE_POSTPROC/ system restart. The target release be
REQ_USER_ROLLBACK_PREP comes active after 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 perform
the complete system backup
Completed with phase:

MAIN_POSTPROC/
SUBMOD_BRIDGE_POSTPROC/
REQ_USER_ROLLBACK_FINAL

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 17]

2. Impact Analysis [page 21]
3. Restrictions During the Runtime of the Bridge Subsystem [page 29]
3.1 Project Planning Aspects
This part of the document contains information about basic project planning aspects.
1. Test Cycles [page 17]

2. Exemplary High-Level Project Plan [page 18]
3. Additional Steps for ZDO [page 19]
4. Estimation of the Right Time for Rollover and Rollback [page 20]
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 21]
• You create an update cookbook

Planning PUBLIC 17
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.

18 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.
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 21].
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 Replication Handling [page 35].
 Recommendation
If SLT is used on a productive system, we strongly recommend performing this test already as part of the
first sandbox iteration.

Planning PUBLIC 19
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
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:

20 PUBLIC Planning
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 21]

2. Exporting Table Statistics to the Productive System [page 23]
3. Impact Analysis Usage [page 24]
4. Applying Best Practice for Impact Analysis [page 28]
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 a 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 are checked by the impact analysis for ZDO:
• Read-only restrictions for users on the bridge subsystem

• Database triggers (such as SLT triggers) that have to be removed from certain tables, or an initial load is
required after the update is complete
• Additional free space on the database required for the cloned tables

Planning PUBLIC 21
• Tables that are smart-switched but have a high number of changes
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 17].
The following SAP Notes are relevant for the impact analysis for ZDO:
• SAP Note 2402270 : Export of Table Statistics for SUM Impact Analysis
• SAP Note 2471883 : SUM Impact Analysis for ZDO
• SAP Note 3092738 : Software Update Manager Toolbox - Central SAP Note
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
Share 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.
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.
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.

22 PUBLIC Planning
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
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.

Planning PUBLIC 23
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 the save subdirectory of the SUM directory.
Note that the save subdirectory is only created by the Software Update Manager during the
Preprocessing roadmap step.
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 <SUM directory>/
abap/save 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.

24 PUBLIC Planning
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.
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:

Planning PUBLIC 25
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 <SUM
directory>/abap/save.
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. Removed 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 up
grade 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 esti
mate on the required database free space for the clone ta
bles.
(5) Result table in ALV grid Displays results at severity, category, and table level.

26 PUBLIC Planning
 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 If database triggers exist in the production system, a reload

can be necessary, or the trigger must be dropped. For more
information, see SLT Replication Handling [page 35].
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 dDuring the upgrade in phase

PARCONV_UPG. This requires an exclusive table lock.
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.

Planning PUBLIC 27
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.
 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 23].
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.

28 PUBLIC Planning
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
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 24].
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 ZDO process:
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.

Planning PUBLIC 29
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 will be 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.

30 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 31]

2. Add-On Handling [page 32]
3. Handling UPL Data Collection Job [page 33]
4. SAP Business Warehouse Extractor Handling [page 33]
5. Silent Data Migration Handling [page 34]
6. SLT Replication Handling [page 35]
7. Usage of Custom Database Schemas [page 38]
8. Backing Up Table Content in the SAP HANA Repository 1.0 [page 38]
9. Migration of Native SAP HANA Database Objects [page 39]
10. Backup Strategy for ZDO [page 40]
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
free space cannot be quantified beforehand because it depends on the scope of maintenance and on the size
of the system.

Preparation PUBLIC 31
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 21].
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 .

32 PUBLIC Preparation
4.4 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:
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.5 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.6 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 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.7 SLT Replication Handling
This section covers aspects with regard to the SAP Landscape Transformation Replication Server
(SLT) and its replication handling.
ZDO supports the SLT replication during an update if the connection between the SLT Server and the system
that is upgraded or updated using ZDO is based on the Remote Function Control (RFC) technique. The
system that is upgraded or updated using ZDO can either be an SLT source system or an SLT target system.
This section only handles the previous case in which the system is an SLT source system and SLT triggers are
present in your system. There is nothing to do for the subsequent case.
Besides an SLT Server setup, SLT can also part of the Core Data Services (CDS) reader and of the SLT
reader scenario of SAP Data Intelligence.
If the system that is upgraded or updated using ZDO of SUM is an SLT source system, SLT replication is
supported until the rollover to the bridge subsystem. You can decide in phase SUMASK_RFC_2_SLT_SERVER to
activate SLT processing so that SLT is also supported on the bridge subsystem. In this case, you may be asked
during this phase for an RFC connection from the system that is upgraded or updated using ZDO to the SLT
server. It must be provided if old /1LT/ SLT triggers exist in your system.
 Note
Depending on the source system and SLT Server configuration, there are two SLT replication logics (in the
following, referred to as "old" and "new"), which are handled slightly different during upgrade or update.
While the triggers have the prefix /1LT/ in the old SLT replication logic, they have the prefix /1DH/ in the
new SLT replication logic. The new SLT triggers can only be present on SAP S/4HANA 2020 or newer
versions.
SLT Is Not Supported on Bridge Subsystem
In the following, you see a phase overview when SLT is not enabled on the bridge subsystem.

SLT Is Supported on Bridge Subsystem
In the following, you see a phase overview when SLT is enabled on the bridge subsystem.
If SLT handling on the bridge is enabled in phase SUMASK_RFC_2_SLT_SERVER, SUM looks for all SLT trigger
on the system. If it finds
• old SLT triggers: It asks for a list of RFC connections to all SLT server of your setup
• only new triggers: It doesn't ask for a list of RFC connections
• no triggers: SUM runs with disabled SLT on the bridge
On XCLA tables, SLT replication is still not supported on the bridge subsystem. The phases
RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_PRE and RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_AFT
check, whether there are XCLA tables that are also part of the SLT replication. The triggers must be removed at
the latest in phase RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_AFT.
 Caution
Delete in phase RUN_CHECK_SLT_TRIGGER_BRI_ROLL only triggers. SLT logging tables must not be
deleted, otherwise SUM run into errors.
Additional requirements:
• SAP HANA database version 2.00.42 or higher

• For new SLT Trigger replications, CL_DHCDC_ZDO_UPGRADE_FACADE is part of the source system
• For new SLT Trigger replications, the SLT Observer job runtime is reduced to 10 minutes or less
• Do not start or stop SLT replication for a table after phase SUMASK_RFC_2_SLT_SERVER, otherwise SUM
can run into errors.
• Use the Note Analyzer to ensure that the latest SLT-related corrections are implemented before you start
the SUM procedure with ZDO. Both your SLT servers and the system being updated or upgraded with ZDO
must be up to date. For more information, see SAP Notes 2596411 and 3016862 .

In addition, you can find a complete list of the relevant SAP Notes in the corresponding SAP Notes "Release
Information SLT", which are listed in SAP Note 2572945 .
• The connection between the SLT Server and the system that is updated or upgraded using ZDO must be
RFC-based. Replication via a database connection is not supported.
Setup of the RFC Connection to the SLT Server
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 upgraded or updated using ZDO to the SLT Server.
Create the RFC destination manually in the source system with the following attributes:
Type: ABAP
Destination: Central SLT server
Roles assigned to the user: SAP_IUUC_REPL_ADMIN, SAP_IUUC_REPL_REMOTE, and

SAP_MWB_PROJECT_MANAGER
At the end of the update, you are prompted to delete the RFC destinations in phase
REQ_DEL_RFC_SLT_SERVER.
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
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:
 Example

 Caution
The value change does not affect a currently running observer job.
For more information on managing your SLT replication, see the documentation on SAP Help Portal: Managing
the Replication Process Using Transaction LTRC
4.8 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 39], 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.9 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.
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.10 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.

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.11 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 48].

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.

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 42]

2. Resetting the ZDO Procedure [page 48]
3. Special Features for ZDO [page 49]
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 42]
• Configuration [page 43]
• Execution [page 44]
• Checks [page 43]
• Postprocessing [page 47]
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

42 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 40].
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).

Running the Software Update Manager PUBLIC 43
Phase Check
RUN_ZDO_CONSISTENCY_CHECK_* In this phase, the ZDO Consistency Check for ABAP diction
ary objects and SLT setup is performed.
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 24].
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 44]

• Monitoring the Reconnection of Work Processes [page 45]
• Monitoring the Change Recording and Replay Phases [page 46]
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 39] 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.
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
You can monitor the replay phases and the replay progress of your update or upgrade with ZDO.
Context
Proceed as follows:
Procedure
Call transaction CRR_CONTROL for monitoring.
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.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 40].
Completion of User Rollback to the Original System
The update procedure is complete. All users can log on again to the original productive system. Confirm the
dialog in SUM by choosing Next.

5.2 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 40]), the reset function is available until phase
REQ_ZDO_SYSTEM_BACKUP.
To reset the procedure, proceed as follows. After finishing both steps, you can start another update using
Software Update Manager.

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.
 Note
This step 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.
5.3 Special Features for ZDO
This section describes special features for the ZDO:
1. Restoring Table Content in the SAP HANA Repository 1.0 [page 49]
2. Final Validation [page 50]
3. Bridge and Update Subsystems During the Update [page 50]
4. Transition of Users to Bridge Subsystem [page 50]
5. Database Reconnect Transition Method [page 51]
6. Locks on the Bridge Subsystem [page 52]
5.3.1 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.

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.3.2 Final Validation
Perform a final validation. Check custom development activities and third-party applications by scans and test
runs.
5.3.3 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.3.4 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
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.3.5 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.
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
45].
5.3.6 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 re
main 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.

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 33].
• Reactivate BW extractors. For more information, see SAP Business Warehouse Extractor Handling [page
33].
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.

Follow-Up Activities PUBLIC 53
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 54]

2. Known Issues [page 55]
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 54]

• Analyze short dumps [page 54]
• Check the background job overview [page 55]
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.

54 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 56]
• Reset: Error in Phase RUN_RSDB02CK_REV [page 56]
• Cleaning up the Orphaned Update Records [page 57]
• Error in File LONGPOST.Log [page 57]
• Error in Phase MAIN_POSTCLEAN/TOOLIMP_DELETE_ABAP [page 58]
• Error in Phase MAIN_NEWBAS/XPRAS_AIMMRG [page 58]
• Remaining Views After Reset of a ZDO Update to SAP S/4HANA 2020 [page 59]
• Performance of Phase SQLRUNTASK_FDCT_TRANSFER on SAP HANA DATABASE [page 59]
• During Reset System Separation Between Bridge System and Upgrade System Isn't Correctly Reset [page
60]
• Error in PARRUN_ZDO_CONSISTENCY_CHECK or RUN_ZDO_CONSISTENCY_CHECK_POST [page 61]
• Error in Phase RUN_RSPTBFIL_ZDM_CHECK_BW [page 62]

Troubleshooting PUBLIC 55
Running SUM with ZDO After a Previous Run Has Been Reset
Symptom Solution
During the reset of a ZDO update, newly added database ta Make sure in transaction DB02 that there are no additional
bles 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

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 up
date 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 ta
ble.
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

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 RDDIMPDP
• Or after event: SAP_TRIGGER_RDDIMPDP
was scheduled for the upgrade subsystem in phase
MAIN_NEWBAS/JOB_RDDNEWPP. After switching off the sub Multiple instances of the RDDIMPDP batch job must not be
system 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"
[...]

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, cre
check of your SAP HANA database. It describes how to use
ate 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

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..

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 stops in phase 1. Check if the table is part of SLT replication.
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 Update
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 cannot
sages such as: resolve the inconsistencies, report an incident on compo
nent 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"

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 appli
cations are used in SAP S/4HANA and use the deter
Furthermore, the log file contains detailed information about mined 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 076 Advanced Data Stores: 2 2. If the functional teams confirm that SAP BW objects are
used by the business applications, the SUM procedure
A4 ESZDM 002 0EPM_ADSO1
with ZDO is not possible. If in doubt, report an incident
A4 ESZDM 002 0EPM_ADSO2 on the application component that uses the active SAP
BW object.
A4 ESZDM_SRC 077 Data Stores: 1
3. If you can confirm that SAP BW is not used by the func
A4 ESZDM 002 0BPM_DS01 tional teams, but the check has determined the active
use of data warehousing, open an incident on compo
A4 ESZDM_SRC 078 Info Cubes: 1
nent BC-UPG-DTM-TLA.
A4 ESZDM 002 0BPCBPFVPX
A4 ESZDM_SRC 079 Persistent Staging

Areas: 0
 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 lim
ited to 25. To get a complete object list, execute the re
port RSUPG_CHECK_BW.

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 a 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.

Important Disclaimers and Legal Information PUBLIC 63
www.sap.com/contactsap
© 2022 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

Zdo Sum20 S4hana

Uploaded by

Copyright:

Available Formats

Zdo Sum20 S4hana

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zdo Sum20 S4hana

Uploaded by

Copyright:

Available Formats

Upgrade Guide | PUBLIC

Software Update Manager 2.0 SP15

Zero Downtime Option for SAP S/4HANA

THE BEST RUN

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

Zero Downtime Option for SAP S/4HANA

Zero Downtime Option for SAP S/4HANA

Version Date Description

1.0 2022-10-10 Initial version

Zero Downtime Option for SAP S/4HANA

1. About This Document [page 5]

1.1 About This Document

1.2 Required SAP Notes and Further Documentation

Zero Downtime Option for SAP S/4HANA

SAP Note Title

2707731 Prerequisites and Restrictions of Zero Downtime Option of

These SAP Notes have more information about the

• supported products and releases

1.3 New Features

Feature Description Availability

Zero Downtime Option for SAP S/4HANA

1.4 Naming Conventions

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

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

SAPup An executable that is called internally by SUM.

Zero Downtime Option for SAP S/4HANA

CDC is short for: change data capturing

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

SUM Short for: Software Update Manager

The recommended standard path of the SUM directory is: usr

sap <SID> SUM

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

V1 Stands for version 1 and represents the source release.

V2 Stands for version 2 and represents the target release.

Zero Downtime Option for SAP S/4HANA

1. The ZDO Concept [page 9]

2.1 The ZDO Concept

The ZDO approach is beneficial for the following maintenance events:

• Applying support package stacks

Zero Downtime Option for SAP S/4HANA

Zero Downtime Option for SAP S/4HANA

2.3 Technical Details of the Zero Downtime Option

Zero Downtime Option for SAP S/4HANA

The General Solution Approach

Zero Downtime Option for SAP S/4HANA

The Bridge Concept

Zero Downtime Option for SAP S/4HANA

2.4 Specific Phases for ZDO

Phase Purpose Comment

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

For more information, see Backup

RUN_RSPTBFIL_ZDM_CHECK_BW SAP BW Check Checks for an active SAP BW system.

• NO_BW_SCOPE: System scope

Zero Downtime Option for SAP S/4HANA

For example, ZDO can only handle data­

See also in chapter Known Issues [page

55] the section Error in Phase

ST With Regard To The SLT Setup .

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Table classification to calculate the han­ In phase

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

For example, ZDO can only handle data

MAIN_SHDIMP/SUBMOD_SHD2_RUN/ Table classification to calculate the han In phase

A possible business impact can be esti

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