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 CDAT, and
- 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 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
- Acquire an exclusive table lock for table
- Rename table
- Release the exclusive table lock for table
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
- 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
- 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_LKPMis 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.