Enabling Parallel Execution of Production Operation and SUM with Table Classification

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.

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

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

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

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