Preparing the System for an Upgrade or Update with Zero Downtime Option

Objectives

After completing this lesson, you will be able to:
  • Prepare the source system for a maintenance with ZDO
  • Identify and assess the usage type of SAP Business Warehouse in an SAP S/4HANA system
  • Check ZDO-compliance on database level
  • Describe the concept of Silent Data Migration Infrastructure
  • Check ZDO-compliance of the Software Stack

Preparation of the Source System

This section lists the activities that are recommended to prepare the source system for Zero Downtime Option (ZDO) of Software Update Manager.

In order to upgrade or update SAP S/4HANA® systems using Zero Downtime Option, a set of preliminary steps have to be fulfilled. However, the steps are not all manual activities to be executed along with Software Update Manager but also guidelines that have to be followed by the software vendor SAP as well as third-party add-on vendors.

Preparation of the Source System

Before starting a zero-downtime project for SAP S/4HANA, preliminary activities have to be performed. Here is a summary of the preparatory steps described in the latest version of the ZDO guide that can be found in the SAP Help Portal:

  • Hardware requirements
  • Add-on handling
  • SAP BW extractors
  • ZDO Preliminary Checks
  • Migration of native SAP HANA® objects
  • Usage of custom-created database schemata in SAP HANA
  • Handling of SLT triggers
  • Backup strategy for ZDO

In this lesson, ZDO Preliminary Checks available In Software Update Manager Toolbox are discussed. Migration of native SAP HANA objects and the usage of custom-created database schemata as well as details on SLT trigger handling and the backup strategy can be found in later lessons. For all other topics, follow the steps described in the ZDO guide.

ZDO Preliminary Checks using Software Update Manager Toolbox

Software Update Manager Toolbox delivers ZDO Preliminary Checks for the following topics:

  • Usage of SAP Business Warehouse
  • Status of Silent Data Migration Infrastructure
  • Consistency check of data dictionary and database
  • Consistency check of SAP HANA content deployment
  • Consistency check of active nametab objects
  • Check ZDO compliance of SLT setup
This screenshot shows the tool ZDO Preliminary Checks and Software Update Manager Toolbox.

Note

By using the information icon in the menu bar, an extended application help opens and it explains every check in detail.

1) Usage of SAP Business Warehouse

The usage of SAP Business Warehouse differs depending on the applications used in the SAP S/4HANA system. This check requires the following SAP Notes to be applied before the check can be executed:

  • SAP Note 3006375 - BW operating mode and zero downtime maintenance
  • SAP Note 3098968 - BW operating mode and zero downtime maintenance
  • SAP Note 3154703 - Enhance CL_RS_UTILITIES=>GET_SYSTEM_SCOPE

If a critical object like an Info Cube, Data Store, or Advanced Data Store is found, these object(s) will have to be checked in detail as they potentially leverage data warehousing, which is not supported by ZDO. This is discussed in detail in a later lesson.

The exemplary result of a system with no usage of SAP Business Warehouse looks as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for SAP Business Warehouse usage.

2) Status of Silent Data Migration Infrastructure

Typically, Silent Data Migration Infrastructure (SDMI) classes have to be finished in all clients prior to an upgrade being started. However, there might also be SDMI classes with an extended release validity. This check outlines the SDMI classes that must be finished before starting the ZDO upgrade procedure. The exemplary result is as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for Silent Data Migration Infrastructure execution status.

3) Consistency Check of Data Dictionary and Database

During a ZDO update or upgrade, all database and data dictionary objects have to be in a consistent state. The check determines a broad spectrum of potential erroneous objects, like the following:

  • Missing tables and indexes in data dictionary, but present in database
  • Inconsistent indexes, views, and tables

If all objects are consistent, the output looks as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for data dictionary consistency.

4) Consistency Check of SAP HANA Content Deployment

This check validates the consistency of all objects in SAP HANA content deployed by HANA Transport Container (HTC), SAP HANA Transport for ABAP (HTA), and SAP HANA Deployment Infrastructure (HDI). During the ZDO procedure, the HDI containers need to be re-deployed for the bridge subsystem. Hence, all objects have to be in a consistent state. The exemplary result is as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for SAP HANA content.

5) Consistency Check of Active Nametab Objects

The nametab (short for name table), which is sometimes also called the runtime object, is read by the kernel in all places when information about ABAP Dictionary objects is requested. Inconsistent nametabs can have an impact on the ZDO procedure, especially in case tables are classified as cloned tables. Hence, this check provides a consistency check if all active nametab objects have a corresponding object in the ABAP Dictionary. In addition, it is checked if the ABAP dictionary object belongs to a valid and consistent database table. The exemplary result is as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for runtime (so-called nametab) objects.

6) Check ZDO Compliance of SAP Landscape Transformation Replication setup

ZDO supports RFC-based SLT replication. It is essential that the SAP Landscape Transformation Replication setup is fully consistent. In case SAP Landscape Transformation Replication triggers are attached to a database table, a logging table must exist in the ABAP Dictionary as well as on database level. The same holds true for the other way round: if a logging table exists, triggers must be present in the database. The exemplary result is as follows:

This screenshot shows the result screen of the Software Update Manager Toolbox check for the setup of SAP Landscape Transformation Replication triggers.

Further Information:

Usage of SAP Business Warehouse Configuration in SAP S/4HANA

This section offers details on the analysis of the usage type of SAP Business Warehouse (BW) in an SAP S/4HANA® system and the potential impact on a Zero Downtime Option (ZDO) procedure.

During the check phases, Software Update Manager checks for the active usage of SAP Business Warehouse (BW) configuration in the system. SAP BW distinguishes between three different operating modes:

  1. Data Warehouse
  2. Embedded BW
  3. Embedded Analytics

Furthermore, SAP Note 2952947 describes these three different operating modes of SAP BW in detail.

Details on Phase RUN_RSPTBFIL_ZDM_CHECK_BW

The usage of SAP Business Warehouse is also checked by Software Update Manager in the phase RUN_RSPTBFIL_ZDM_CHECK_BW. The check shows all BW objects that are not ZDO-compliant and cannot be used during bridge execution of a ZDO upgrade.

The check phase RUN_RSPTBFIL_ZDM_CHECK_BW of Software Update Manager writes the output in the log file RSZDM_CHK_BW.<SID>.

Code Snippet
1234567891011121314
A4 ESUPG 001 ---------------------------------------------------------------------
A4 ESUPG 002 " "
A4 ESUPG 665 Report name ...: "RSPTBFIL_ZDM_SRC" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
A4 ESUPG 302 Log name: "/usr/sap/<SID>/SUM/abap/tmp/RSZDM_CHK_BW.PPM"
A4 ESUPG 304 Start time.....: "15.07.2021" "17:41:55"
A4 ESUPG 001 ---------------------------------------------------------------------
A4 ESZDM_SRC 070 Begin check for active BW. Possible for release >= 753
A4 ESZDM_SRC 073 System scope is "ANALYTICS_ONLY", ZDO is supported
A4 ESZDM_SRC 071 End check for active BW. Possible for release >= 753
A4 ESUPG 001 ---------------------------------------------------------------------
A4 ESUPG 665 Report name ...: "RSPTBFIL_ZDM_SRC" Component: "BC-UPG-TLS-TLA" "(Upgrade Tools for ABAP)"
A4 ESUPG 304 Start time.....: "15.07.2021" "17:41:55"
A4 ESUPG 305 End time ......: "15.07.2021" "17:41:55"
A4 ESUPG 001 ---------------------------------------------------------------------

The return value of this phase can be different depending on the operating mode used in the SAP S/4HANA system. Hence, the message in the log file is either a success message for supported operating modes or an error message for unsupported operating modes:

  • NO_BW_SCOPE: A4 ESZDM_SRC 073 System scope is "NO_BW_SCOPE", ZDO is supported
  • ANALYTICS_ONLY: A4 ESZDM_SRC 073 System scope is "ANALYTICS_ONLY", ZDO is supported
  • DATA_WAREHOUSE: A2EESZDM_SRC 074 System scope is "DATA_WAREHOUSE", ZDO is not supported, see SAP Note 2707731

Accepting Unavailability of BW Functionality during Bridge Execution

If the checks identify BW objects that are not ZDO-compliant, the following steps are recommended:

  1. With your functional teams, clarify which business applications are used in SAP S/4HANA and use the determined SAP BW objects (Advanced Data Stores, Data Stores, InfoCubes, or Persistent Staging Areas).
  2. If the functional teams confirm that SAP BW objects are used by the business applications, the Software Update Manager procedure with ZDO is not possible. If there is doubt, report an incident on the application component that uses the active SAP BW object.
  3. If you can confirm that SAP BW is not used by the functional teams or the use of SAP BW can be restricted during the bridge phase, you can skip the check.

    To accept unsupported SAP BW objects and continue the procedure, create the file ZDO_BW_ALLOW.LST and add it to the var subdirectory of the Software Update Manager Directory. In the file, specify in the form of a simple list the SAP BW objects that can be ignored. Enter one object name per line without separators as end-of-line representation.

Further Information

Native SAP HANA Objects and Custom-Created Database Schemata

This section contains migration steps for SAP HANA® objects to SAP HANA Transport for ABAP (HTA) for SAP HANA Deployment Infrastructure (HDI) technology and information on the handling of custom-created database schemata with Zero Downtime Option (ZDO).

Migration of Native SAP HANA Objects

In case native SAP HANA artifacts are leveraged in the SAP S/4HANA® system, content migration must be carried out prior to the ZDO upgrade project.

In SAP HANA databases, native SAP HANA database objects are stored in the SAP HANA repository 1.0, also known by the technical database schema name _SYS_BIC. To ensure a proper encapsulation of the source and target releases during updates with ZDO, the database objects and database artifacts being changed have to be cloned. This ensures that end-users will not see any change done by Software Update Manager that would reflect the target release.

The SAP HANA repository 1.0 (_SYS_BIC) is not able to exist in two different versions like source and target release, as it is a so-called singleton schema, which must exist only once in a tenant database. In contrast to ABAP Dictionary objects where the bridge operates on a different schema, this is not possible for _SYS_BIC as cloning is not permitted.

If the upgrade changes objects stored in _SYS_BIC, the end-users on the bridge subsystem would immediately see the changes done by Software Update Manager. This collides with the key principle of ZDO that states that source and target releases have to be encapsulated and the bridge subsystem must only see content and objects belonging to the source release.

Typically, the following object types are stored in the SAP HANA repository 1.0:

  • Analytic views
  • Attribute views
  • Calculation views
  • Procedures
  • And so on

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

Note

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

End-to-End Process of Migrating SAP HANA Repository 1.0 to HDI

This image displays four columns with generic pictograms on top. Each column is titled with one step of the HDI migration. Each column is titled with one step of the HDI migration.

  • First, find out if native SAP HANA objects are available and in use. If native SAP HANA objects are not in use, no further action is required.
  • For some applications delivered by SAP, migration reports and documentation exist:
    • SAP Business Planning and Consolidation: SAP Note 2649528 - HDI Migration for SAP BPC Optimized for SAP S/4HANA
    • SAP Real-Time Consolidation: SAP Note 2643245 - HDI Migration for Real-Time Consolidation in SAP S/4HANA 1709
    • SAP Customer Activity Repository: SAP Note 3103336 - Prepare SAP Customer Activity Repository for Zero Downtime Upgrades
  • For custom-created objects in _SYS_BIC, the migration has to be done manually. For details and examples, see the references below in section Further information.
  • The migration, as well as the functional validation of the newly created objects in HDI, should be done prior to the ZDO upgrade project.

Note

In case of custom-created objects, also consider the adaptation of the ABAP code that accesses native SAP HANA objects. If the callers are not changed, the newly migrated objects would not be used.

Typically, native SAP HANA objects are accessed in the ABAP code either using ABAP Managed Database Procedures (AMDP) or ABAP Database Connectivity (ADBC).

AMDP:

ADBC:

  • For ADBC, you need to use a provided API to retrieve the native schema.

  • For details, check the tutorial Developing and Consuming HDI Objects in ABAP: https://help.sap.com/viewer/6811c09434084fd1bc4f40e66913ce11/1809BW.001/en-US/d9e50716c5ea4738a72b9dcbeefada1e.html

    Note

    Quote from the tutorial Developing and Consuming HDI Objects in ABAP"We do not recommend that you use ABAP Database Connectivity (ADBC). However, if you use it, you can read the physical container name using the following API: DATA(lv_physical) = cl_cts_hta_hdi_container_api=>get_physical_container( 'Z_HTA_HDI_DEMO_CONT' )."

Further Information

Usage of Custom-Created Database Schemata in SAP HANA

After the rollover to the bridge subsystem (Software Update Manager phase REQ_USER_ROLLOVER_PREP), end-users access the bridge database schema through the connection user having the appendix SHD like SAPHANADBSHD. The bridge database connection user automatically gets the relevant privileges required for the bridge database schema to access ABAP Dictionary objects related to the source release.

Note

If custom-created database schemata exist, Software Update Manager is not able to detect these schemata. Hence, the bridge database connection user will not be able to access the custom-created database schemata by default.

By default, the ABAP coding executed by the end-user on the bridge subsystem fails since the bridge database user SAPHANADBSHD does not have the required privileges to call the function stored in the custom-created database schema.

Note

To access objects in the custom-created database schema, the bridge user (that is, SAPHANADBSHD) needs the same privileges as the original user (that is, SAPHANADB). To avoid short dumps for end-users, the privileges have to be granted manually by your database administrator before rolling over to the bridge subsystem.

The Silent Data Migration Infrastructure

This section introduces the Silent Data Migration Infrastructure (SDMI). SDMI decouples the simplification of a data model from the actual change in the business application.

Migration of application data usually happens during release upgrades during downtime by XPRA programs or XCLA classes in the phase XPRAS_AIMMRG. When running zero-downtime upgrades, XPRA programs and XCLA classes are executed during uptime while the business operates on the bridge subsystem. If such migrations of application data are triggered by XPRA programs and XCLA classes, the affected application tables would be set to read-only during the bridge runtime. Setting application tables to read-only can cause severe business impact as vital business processes would potentially be blocked.

This image shows three columns displaying the benefits of the silent data migration. Each column is topped by a generic pictogram.

With SAP S/4HANA® 1909, SAP introduced a new framework to deliver the simplification of data models in a zero-downtime compliant format. Silent Data Migration Infrastructure allows the application developers to decouple the data model change from the functional change of a business application. In the aftermath of an upgrade, the application already runs on the target version. The old data model is still compatible with the new applications.

In contrast, the Silent Data Migration Infrastructure (SDMI) is fully compatible with zero-downtime upgrades. The migration does not happen during the Software Update Manager upgrade but is triggered when the upgrade is finished during regular business operations. This can only be achieved by decoupling the structural change from the functional change of the business application.

Example of a Silent Data Migration

Note

You cannot choose if a change, like the one in this example, should be done through XPRA, XCLA, or silent data migration. How a change is delivered in a release upgrade of SAP S/4HANA is decided by the application developer of SAP.

After a successful upgrade, the background job used by Silent Data Migration Infrastructure is scheduled using the job repository (job name: SAP_SDM_EXECUTOR_ONLINE_MIGR) and starts automatically for each client. The job requires a user with appropriate authorization that can either be created during the Software Update Manager execution or using the transaction, SDM_USER, after the upgrade.

The progress of silent data migrations can be monitored using the transaction SDM_MON.

Further Information

ZDO Compliance and Enablement

This section contains information about the necessary enablement of development objects for Zero Downtime Option (ZDO) of Software Update Manager.

Developing software that can be maintained using ZDO means that software developers need to follow a strict set of development guidelines. These changes in software are delivered in upgrades and updates that can be critical for ZDO:

  • Structural changes to the persistence layer
  • Delivering new transport objects linked to After-Import-Methods (AIM)
  • New application-defined procedures like After-Import-Methods (AIM) or XPRA programs
This image shows three columns displaying the pieces of enablement for ZDO. Each column is topped by a generic pictogram.
  • Within SAP, all development systems are connected to ABAP test cockpit, which considers the ZDO development guidelines.
  • All software changes planned to be released to customer will run against the ABAP test cockpit checks with focus on ZDO compliance.
  • By running the checks in a proactive manner, it can be ensured that software that will be delivered to customer meets the ZDO development guidelines.
  • Not only changes of database objects, but also new development of application-defined procedures like After-Import-Methods or new XPRA programs need to follow the ZDO development guidelines.
  • One of the key principles of ZDO is the proper encapsulation of source and target release. This can only be achieved by knowing every table that is either changed or accessed by the upgrade.
  • The so-called ZDO enablement of application-defined procedures contains the meta-data information on tables accessed when executing the source code.
  • The ZDO enablement of AIMs and XPRAs is required by Software Update Manager to identify the tables that are accessed when running these functions, methods, and reports in the phase XPRAS_AIMMRG.
  • In case a ZDO enablement is missing, the software vendor can ship the enhancement with the upcoming support packages. However, in most cases, this is too late when a ZDO project is already running. Hence, for SAP software components, the ZDO enablement is also shipped with new patch levels of Software Update Manager.
  • In exceptional cases, complex changes might be shipped for certain applications. These complex changes can have an impact in the application during the ZDO upgrade.
  • For such cases, the application component provides a restriction SAP Note that describes the change, the validity of the restriction, as well as the impact to the business.
  • All known restrictions and limitations are linked in the central ZDO SAP Note 2707731.

Note

Note that any software package and transport, which is planned to be applied with ZDO, needs to be ZDO-compliant. More information about development guidelines can be found on help.sap.com.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn