Deciding on the Handling of SLT Triggers during a ZDO Maintenance Event

Objective

After completing this lesson, you will be able to decide on SLT trigger handling during ZDO execution

SLT Database Trigger Handling in ZDO

This section introduces the options for SLT replication during a Zero Downtime Option (ZDO) maintenance event.

When you are updating or upgrading an SAP S/4HANA® system using ZDO, the replication of changes using SAP Landscape Transformation Replication Server (SLT) is supported. SLT replication can also be used as part of SAP Data Intelligence and Operational Data Provisioning. The replication type is important to be checked:

Note

Only RFC-based replication is supported by ZDO. Replication using native database connections cannot be determined by Software Update Manager. Further information on the different SLT replication types can be found in SAP Note 1605140.

There are four cases that have to be distinguished:

  1. No SLT replication: SLT is not used in any system to be upgraded using ZDO. SLT-specific considerations are not relevant.
  2. Software Update Manager execution without SLT replication: SLT is used in production. The current system that is being upgraded (for example, a sandbox system) does not have an SLT set up. In that case, there is no special handling of SLT by the Software Update Manager in the current system. This difference will be brought up by Software Update Manager. Also, the Impact Analysis outlines the tables on which SLT triggers cannot be preserved during rollback to the original system.
  3. Subscription-based change data capture mechanism is used: SLT is set up in production using the subscription-based change data capture mechanism. The current system has the same SLT setup as production. SLT replication continues during the Software Update Manager uptime on the bridge subsystem by default. For details on the handling of SLT by the Software Update Manager, see below.
  4. Legacy change data capture mechanism is used: SLT is set up in production using the legacy change data capture mechanism (or a mixed scenario with subscription-based change data capture mechanism). The current system has the same SLT setup as production. The handling of SLT by the Software Update Manager depends on whether SLT replication is supposed to be active during uptime on bridge subsystem. For details, please refer to the text below.
Depending on the source system and SLT server configuration, there are two different technologies used by SLT replication. Database triggers having the prefix /1LT/ are using the legacy change data capture mechanism. The subscription-based change data capture mechanism is used by triggers having the prefix /1DH/. This is possible from SAP S/4HANA 2020 onwards.

Case 3: Subscription-Based Change Data Capture Mechanism

When Software Update Manager is launched on a system where the subscription-based change data capture mechanism is used (triggers with prefix /1DH/*) and ZDO is selected as downtime-optimization approach, SLT replication is kept active during uptime on bridge subsystem by default.

Prerequisites and restrictions are as follows (refer to the latest ZDO guide for updated information):

  • At least SAP HANA® revision 2.0.00.42.
  • Various SAP Notes that have to be applied in the source system.
  • Various SAP Notes that have to be applied in the central SLT server.
The list of SAP Notes is volatile and gets extended. Hence, make sure that you always have the latest SLT-related corrections applied before starting the ZDO upgrade. For this, the so-called Note Analyzer is provided (for details, see SAP Notes 2596411 and 3016862). In addition, the SLT Release Information Notes listed in SAP Note 2572945 provide the full list of relevant SAP Notes.This image shows the Software Update Manager process and highlights relevant phases for a ZDO upgrade with active SLT replication during bridge execution. This is relevant for setups using subscription-based change data capture mechanism with /1DH/* triggers. SLT is kept active for the uptime on bridge. Not all triggers can be preserved. Impact Analysis prints out the full list. For affected tables on which the triggers cannot be preserved, an initial load is required after the restart of the application server.
  • In the phase RUN_ZDO_SLT_IMPANA_CONSISTENCY Software Update Manager checks whether the tables with SLT triggers in the file ZDIMPANA.ZIP matches the tables with SLT triggers in the system on which the Software Update Manager is running. If there is a discrepancy, the Software Update Manager stops with an error message. A mismatch might indicate a different setup of the system where statistical data is exported from (typically production system) and the current system. If the mismatch is intentional, the error can be ignored.
  • As part of the ZDO consistency check in the phase PARRUN_ZDO_CONSISTENCY_CHECK, Software Update Manager verifies if the SLT setup is valid.
  • The Impact Analysis outlines the tables that have SLT triggers but have to be cloned by ZDO. This helps to elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.
  • Shortly before the end-users are transitioned to the bridge subsystem, the phase RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_PRE informs about any non-SLT triggers that need to be dropped. The phase is equipped with an ignore option. In the next trigger check phase, they have to be deleted.
  • When the system is restarted, as part of the ramp up activities, an initial load is needed for all switch, clone, and XCLA tables having SLT triggers. Tables handled as shared by Software Update Manager, are not affected.

    Note

    In general, all of these tables had two different versions during the ZDO upgrade. Only the source version of the tables was equipped with the SLT trigger. The new version of the tables that belong to the target release no longer have SLT triggers. Hence, it is mandatory to perform an initial load for such tables in the SLT cockpit.

Case 4: Legacy Change Data Capture Mechanism

When Software Update Manager is launched on a system where the legacy change data capture mechanism is used (triggers with prefix /1LT/*) and ZDO is selected as downtime-optimization approach, the phase SUMASK_RFC_2_SLT_SERVER in Configuration automatically determines if the system currently being upgraded uses SLT replication based on SLT triggers found in the system. This applies to the described cases 4a and 4b below.

This image shows two screenshots from Software Update Manager. The tool is in dialog in phase SUMASK_RFC_2_SLT_SERVER where the decision is made whether SLT should be kept active during bridge execution. This dialog only appears with legacy change data capture mechanism with /1LT/* triggers (and mixed scenarios with subscription-based change data capture mechanism).

The checkbox Yes, run ZDO with active SLT triggers in the phase SUMASK_RFC_2_SLT_SERVER is checked. To keep the SLT replication active during the bridge runtime, an RFC destination for each of the connected SAP Landscape Transformation Replication servers has to be provided to Software Update Manager.

The RFC destination has to be of type ABAP. The user provided to the SLT server has to have at least the following user roles:

  • SAP_IUUC_REPL_ADMIN
  • SAP_IUUC_REPL_REMOTE
  • SAP_MWB_PROJECT_MANAGER

Further details on how to create the RFC destination can be found in the latest ZDO guide.

These RFC destinations are used to prepare the database triggers needed during the bridge runtime. This is only relevant if SLT triggers from legacy change data capture mechanism with the prefix /1LT/ are used and determined by Software Update Manager.

Additional prerequisites and restrictions are as follows (refer to the latest ZDO guide for updated information):

  • At least SAP HANA® revision 2.0.00.42.
  • After the phase SUMASK_RFC_2_SLT_SERVER, it is not allowed to change the SLT replication.
  • Various SAP Notes that have to be applied in the source system.
  • Various SAP Notes that have to be applied in the central SLT server.

Note

The list of SAP Notes is volatile and still gets extended. Hence, make sure that you always have the latest SLT-related corrections applied before starting the ZDO upgrade. For this, the so-called Note Analyzer is provided (for details, see SAP Notes 2596411 and 3016862). In addition, the SLT Release Information Notes listed in SAP Note 2572945 provide the full list of relevant SAP Notes.
This image shows the Software Update Manager process and highlights the relevant phases for a ZDO upgrade with active SLT replication during bridge execution. This is relevant for setups using the legacy change data capture mechanism with /1LT/* triggers (and mixed scenarios with subscription-based change data capture mechanism). SLT is kept active for the uptime on bridge. Not all triggers can be preserved. Impact Analysis prints out the full list. For affected tables on which the triggers cannot be preserved an initial load is required after the restart of the application server.
  • In the phase RUN_ZDO_SLT_IMPANA_CONSISTENCY Software Update Manager checks whether the tables with SLT triggers in the file ZDIMPANA.ZIP matches the tables with SLT triggers in the system on which the Software Update Manager is running. If there is a discrepancy, the Software Update Manager stops with an error message. A mismatch might indicate a different setup of the system where statistical data is exported from (typically production system) and the current system. If the mismatch is intentional, the error can be ignored.
  • In phase SUMASK_RFC_2_SLT_SERVER the dialog deciding the SLT handling is displayed. When the decision on the phase SUMASK_RFC_2_SLT_SERVER was made that SLT replication should be kept active, the RFC destinations to the SLT servers has to be provided. The list of SLT Servers is written to file /SUM/var/SLT_SERVER_RFCDESTS.LST. The file can be extended in case a destination was forgotten
  • As part of the ZDO consistency check in the phase PARRUN_ZDO_CONSISTENCY_CHECK, Software Update Manager verifies if the SLT setup is valid if SLT is active.
  • The Impact Analysis outlines the tables having SLT triggers but have to be cloned by ZDO. This helps to elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.
  • Shortly before the end-users are transitioned to the bridge subsystem, the phase RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_PRE informs about any non-SLT triggers that need to be dropped. The phase is equipped with an ignore option. In the next trigger check phase, they have to be deleted.
  • At the end of the bridge runtime, the phase REQ_DEL_RFC_2_SLT_SERVER reminds to delete the RFC destination created manually in the phase SUMASK_RFC_2_SLT_SERVER. Of course, it is not mandatory to delete the RFC destination but, for security reasons, it might be required.
  • When the system is restarted, as part of the ramp up activities, an initial load is needed for certain tables having SLT triggers as reported in the Impact Analysis. Tables handled as shared by Software Update Manager are not affected.

4b SLT is Deactivated During Uptime on Bridge Subsystem with Legacy Change Data Capture Mechanism

If the checkbox Yes, run ZDO with active SLT triggers in the phase SUMASK_RFC_2_SLT_SERVER is unchecked, the SLT replication has to be paused or suspended before rolling over to the bridge subsystem.

This image shows the Software Update Manager process and highlights the relevant phases for a ZDO upgrade with deactivated SLT replication during bridge execution. This is relevant for setups using the legacy change data capture mechanism with /1LT/* triggers (and mixed scenarios with subscription-based change data capture mechanism) . SLT needs to be suspended for the uptime on bridge. Additionally, not all triggers can be preserved. Impact Analysis prints out the full list. For affected tables on which the triggers cannot be preserved, an initial load is required after the restart of the application server.
  • In the phase RUN_ZDO_SLT_IMPANA_CONSISTENCY, Software Update Manager checks the number of SLT triggers on tables as reported in the statistics file ZDIMPANA.ZIP and a number of SLT triggers in the current system. A mismatch might indicate a different setup of the system where statistical data is exported from (typically production system) and the current system. If only one of the systems has SLT triggers, Software Update Manager will stop. If the mismatch is intentional, the error can be ignored.
  • In phase SUMASK_RFC_2_SLT_SERVER the dialog deciding the SLT handling is displayed.
  • Software Update Manager detected that the systems uses SLT replication. However, in the phase SUMASK_RFC_2_SLT_SERVER, the decision was taken that SLT replication should be deactivated during the bridge runtime.
  • The Impact Analysis outlines the tables that have SLT triggers but have to be cloned by ZDO. This helps to elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.
  • The first SLT check in the phase RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_PRE lists the tables for which the SLT (or other) triggers have to be dropped. This phase is equipped with an ignore option. The triggers can be kept until the next trigger check phase runs.
  • Shortly after starting the rollover to bridge, the SLT check phase RUN_CHECK_DB_TRIGGER_ZDM_BRI_ROLL_AFT runs. Here, the triggers for the tables listed have to be dropped in order to proceed.
  • Before the rollover to the bridge happens, the SLT replication has to be suspended in the SLT cockpit.
  • When the system is restarted, as part of the ramp up activities, an initial load is needed for certain tables having SLT triggers as reported in the Impact Analysis. Tables handled as shared by Software Update Manager are not affected.

Further Information

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn