Enabling Parallel Execution of Production Operation and SUM with Table Classification


After completing this lesson, you will be able to Describe the concept of cloned and read-only tables.

Table Classification of Zero Downtime Option

This section explains the possible table classification and the impact of classifications during the Zero Downtime Option (ZDO) procedure.

The key principle to run zero-downtime upgrades in parallel with the continuous business operations is to hide all changes performed by Software Update Manager. The bridge subsystem, which is used to continue the productive work, still sees the source release whereas SUM finalizes the target release.

As described in the previous lesson, the two releases run encapsulated. This can only be achieved if SUM knows every change that is performed by the maintenance event.

The Concept of Cloned and Read-only Tables

The main categories of changes performed during an upgrade are as follows:

  • Structural changes to ABAP Data Dictionary objects. These changes are changed using DDL (Data Definition Language) statements.
  • Table content and customizing shipped in transport objects like R3TR TABU, R3TR CDAT, and R3TR VDAT.
  • Application-defined procedures like After-Import-Methods (AIM), XPRA programs, and XCLA classes.

SUM determines these changes and calculates how tables are handled in phase RUN_RSPTBFIL_ZDM_CLASSIFY. The following types are possible:

  • Tables will be shared between the bridge and the upgrade subsystem. This means that the upgrade does not change the tables except where the upgrade adds a new non-key field without default values. In that case, the change can be compensated by the view that is used by the bridge subsystem. Tables classified as shared will not be cloned. No restrictions apply.
  • Tables that will be cloned exist in two variants:
    • Clone with read/write access for bridge and upgrade subsystem. The upgrade changes these tables with simple DDL statements. In addition, it could be that new content or customizing is delivered into such tables. Additional database space required for table clone and change record and replay. No restrictions apply.
    • Clone read-only for the bridge subsystem but the upgrade can write into the target version of the table. Tables that will be read-only for the bridge subsystem receive complex structural change or an application-defined procedure declares that the table has to be read-only. Additional database space required for table clone and change record and replay. Table will be read-only for the business users while working on the bridge subsystem.


Clone read-only tables have to be checked in detail. The Impact Analysis of SUM helps to identify the relevant tables as not all read-only tables are causing an impact for end-users.

The Process of Cloning Tables in ZDO

The process of creating table clones happens when the end-users have been rolled over to the bridge subsystem. Before the process of cloning can be started, SUM has to prepare the existing tables used by the source release (V1). The preparation includes renaming tables from the original name to a temporary name. This ensures that the target version (V2) of the table can be created with the original name.

The rename is called smart-switch and happens in phase EU_SWITCH_ZDM. Here is a pseudo code describing what the phase EU_SWITCH_ZDM does:

  • Acquire an exclusive table lock for table tab1
  • Rename table tab1to tab1temp
  • Release the exclusive table lock for table tab1


Smart-switching tables require an exclusive lock for tables on database level. In case of frequently updated tables (approx. more than 10 changes / second), this can be difficult in peak load hours. For details, see the lesson 'Exclusive Database Locks in ZDO-specific Phases' in unit 8. In addition, unit 4 covers the following in detail: how to deal with findings related to tables that have to be smart-switched but are frequently updated.

Step 1 of the Process of Cloning Tables in ZDO

  • The initial transfer describes the process of creating the initial clone of the table with the same structure.
  • SUM executes the initial transfer in phase SQLRUNTASK_FDCT_TRANSFER.
  • The transfer happens using native database tools.
  • For SAP HANA, the tables are cloned with the statement CREATE TABLE tab(V2) LIKE tab(V1) WITH DATA.
  • From this time, all changes happening on version 1 of the table is captured in an associated logging table.
  • Capturing the changes in the logging table is happening by database triggers that have been created in the table version 1 before the initial transfer was started.

Step 2 of the Process of Cloning Tables in ZDO

  • The process of capturing changes in the logging table continues until the replay of the changes in phase RUN_ZDOREPLAY_REPLAY_LKPM starts.
  • Here, SUM switches the way how changes are captured.
  • The database trigger from table version 1 to the logging table stops capturing changes.
  • From this time, the changes done in table version 1 are synchronously forwarded to table version 2 by another database trigger.
  • All changes captured in the logging table are replayed into table version 2.
  • Replaying the changes and switching over to synchronously replication ensures transactional consistency.

Step 3 of the Process of Cloning Tables in ZDO

  • When the replay in phase RUN_ZDOREPLAY_REPLAY_LKPM is finished, the logging table is no longer used.
  • The upgrade continues with the remaining activities such as adjusting the table version 2 to the target structure, importing table content, or executing application-defined procedures on table version 2.

Log in to track your progress & complete quizzes