Skip to Content
Technical Articles

SLT and database trigger handling with Software Update Manager 2.0

In this blog I describe the handling of SLT and database triggers when running a software maintenance with Software Update Manager 2.0. Readers should be familiar with the SUM, as introduced in the blog Software Update Manager (SUM): introducing the tool for software maintenance.

Abstract: SAP Landscape Transformation Replication Server (SLT) is the standard real-time replication tool for big data from SAP ABAP-based source systems to a side-car scenario (for example: SAP HANA). During the software maintenance, the SUM procedure has several phases which list the database triggers that must be dropped. 

Introduction of the SAP Landscape Transformation Replication Server (SLT)

With SLT, you can synchronize your business data in real time for your system landscape while keeping data transfer volume to a minimum. You can easily replace custom-built data synchronization applications with SLT and benefit from the tight integration with the SAP NetWeaver ABAP Application stack and data model (source: help.sap.com).

 

(click on the image to enlarge it)

 

SLT triggers can be created on all tables of an ABAP-based source system. From an upgrade perspective, we’ve the following high-level table categories:

  • Application tables (e.g. ACDOCA)
  • Customizing tables (e.g. T100)
  • Switch tables (e.g. DD02L):
    • The original switch tables will be replaced by new tables which will be filled by the shadow system during the upgrade procedure

 

SLT trigger check phases in Software Update Manager

The Software Update Manager has several phases to check the existence of database triggers on tables handled during the uptime in the shadow system of the update. Database triggers on tables can cause issues later during the update procedure. The reason is that during the update procedure, switch tables and tables to be converted are replaced in the database with a new version, and the replaced tables are renamed or dropped. If such database triggers exist, the behavior of the Rename or Drop statement for these tables can vary depending on the database.

Example: A table has a database trigger and needs to be converted in the downtime, the conversion would fail if the database trigger is still there. Hence, the trigger must be dropped during the update procedure.

The following table lists all the phases with the information whether the phases are relevant for either the standard, nZDM, or DMO approach of SUM. Additionally, the last column indicates if you can ignore the error of the respective phase.

Phase name Set of tables that will be checked Phase is relevant for the following SUM approaches: Ignoreable
Standard nZDM DMO
RUN_CHECK_SLT_TRIGGER_PRE Switch tables yes yes no yes
RUN_CHECK_SLT_TRIGGER_DTTRANS Switch tables and tables handled in uptime yes yes no yes
RUN_CHECK_SLT_TRIGGER_DOWNTIME Switch tables and tables handled in uptime. The number of tables is identical as in the second check phase. yes yes no no

 

Check 1: RUN_CHECK_SLT_TRIGGER_PRE

The first phase where SUM checks for active database triggers is called RUN_CHECK_SLT_TRIGGER_PRE. The check contains the switch tables. The main purpose of the check is to make the administrator aware of triggers that must be dropped later during the update procedure. However, for this phase the error can be ignored but it should be communicated to the responsible SLT Operations Team. Later on (when check 3 runs), the SLT Operations Team has to drop the triggers listed by the check phase. Hence, the team should get prepared for this task already.

 

Check 2: RUN_CHECK_SLT_TRIGGER_DTTRANS

The Software Update Manager checks again in phase RUN_CHECK_SLT_TRIGGER_DTTRANS shortly before the downtime. The list of database triggers that must be dropped is now complete: it contains the number of tables shown already in check 1 (RUN_CHECK_SLT_TRIGGER_PRE) including the tables handled in the uptime dependent on the selected update approach [standard, nZDM, or DMO]. As in check 1 the SLT Operations Team should be informed and be prepared for the next check. NEW: With SUM 2.0 SP05, this phase is ignorable as well. You can proceed to the dialog phase DOWNCONF_DTTRANS and keep the dialog until your cutover starts.

 

Check 3: RUN_CHECK_SLT_TRIGGER_DOWNTIME

The final check phase RUN_CHECK_SLT_TRIGGER_DOWNTIME comes shortly after you’ve confirmed the dialog DOWNCONF_DTTRANS. The number of tables is identical with the tables listed in check 2 (RUN_CHECK_SLT_TRIGGER_DTTRANS). In this phase at the latest, the SLT Operations Team must resolve the errors. All listed tables are handeled by SUM in a way where the SLT trigger cannot remain on the table due to technical reasons. If the database triggers are not deleted, you will not be able to continue with the update.

The lines in the error log file are like the following:

2EETG010 "Found trigger" "/1LT/REPOSRC" "on switch table" "REPOSRC".

In this case, follow the instructions of SAP Note 1620618 to delete the relevant database triggers. Create the deleted triggers again after the downtime. After the downtime is completed, an initial load of the affected tables is required. For the initial load, the SLT Cockpit is used.

 

Handling of SLT triggers with the standard approach

If you’re running an update using the standard mode, all three phases are running as visualized in the following graphic:

Keep in mind that an initial reload is needed for the tables where the SLT trigger was dropped.

 

 

Handling of SLT triggers with the nZDM approach

With nZDM (near-Zero Downtime Maintenance; for details, see SAP Note 1678564) potentially more table are handled in the uptime to reduce the technical downtime of the update procedure.

Like the standard approach, all three described SLT check phases are running when nZDM is used:

 

However, the strategy with SUM 2.0 SP05 and higher is to handle tables with SLT triggers in downtime dependent on the change to be performed for the particular table. Tables (smaller than isu_max_tab_size) with SLT triggers but receiving either a new index or table content (so-called TABUs) will be handled during downtime. Hence, an initial load after the update is not needed.

Another case would be tables that have to be converted due to structural changes. For those tables, an initial load is needed anyway. Therefore, these table are still handled during uptime. Here’s the decision tree on whether tables are handled in either uptime, or downtime:

 

 

 

Handling of SLT triggers when performing a database migration using DMO

Performing a DMO (Database Migration Option) is different from the SLT handling perspective since the target system runs on a different database. For this reason, no database trigger must be dropped on the source database and no SLT trigger check is running at all. The SLT replication can be kept active until you enter the technical downtime. After the DMO has been completed, an initial load is needed for all tables:

 

 

 

 

Additional information

SAP Landscape Transformation Replication Server

nZDM: near-Zero Downtime Maintenance

DMO: Database Migration Option

Guide for Software Update Manager 2.0

SAP Notes

  • SAP Note 1620618 – Delete Trigger

 

Jens Fieger

Product Management SAP SE, Software Logistics

Be the first to leave a comment
You must be Logged on to comment or reply to a post.