S/4 Hana Upgrades: Process of Cloning Tables in ZDO

[AkumaryafirAk]

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, Software Update Manager 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 the phase EU_SWITCH_ZDM. Here is a pseudo code describing what the phase EU_SWITCH_ZDM does:

• Acquires an exclusive table lock for table tab1
• Renames table tab1 to tab1temp
• Releases 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. Software Update Manager Toolbox offers the tool DB Table Lock analyser to identify suitable timeframes to plan the smart switch in.

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.
• Software Update Manager executes the initial transfer in the 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, Software Update Manager 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 the 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.

[AkumaryafirAk]

• Let's conect and learn together 
• https://www.linkedin.com/in/abhishek-kumar01?utm_source=share&utm_campaign=share_via&utm_content=pro...