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. Update 15.05.2020: minor correction in table for phase overview Update 20.01.2020: added the information about force including tables into uptime handling using nZDM |
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).
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 (see below, for approach specific details) | 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, tables that have to be converted in downtime, and - nZDM only - tables handled in uptime. | yes | yes | no | yes |
| RUN_CHECK_SLT_TRIGGER_DOWNTIME | Switch tables, tables that have to be converted, and - nZDM only - 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 well as the tables that have to be converted in downtime. 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:
However, if you want to force include tables with SLT triggers into uptime handling, you can do this by maintaing an entry in CRRTABLIST.LST. This feature is available since SUM 2.0 SP07.
If you need to include or to exclude single tables into or from the data transfer, proceed as follows:
- In the <DIR_PUT>/control subdirectory of the SUM directory, open the template file CRRTABLIST.LST.
- To include a single table, add the following entry to the existing entries of the CRRTABLIST.LST template file using the following format: I <Tabname>
- To exclude a single table, add the following entry to the existing entries of the CRRTABLIST.LST template file using the following format: E <Tabname>
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
- FAQ - near Zero Downtime Maintenance (nZDM) ABAP
- SAP Note 1678564 - Restrictions, Database-specific Settings, and Troubleshooting of nZDM for SUM
- Impact Analysis as part of Software Update Manager 2.0
DMO: Database Migration Option
Guide for Software Update Manager 2.0
- SL Toolset entry page in the SAP Support Portal: https://support.sap.com/sltoolset > System Maintenance > Guides for SUM 2.0
SAP Notes
- SAP Note 1620618 - Delete Trigger
Jens Fieger
Product Management SAP SE, Software Logistics
- SAP Managed Tags:
3 Comments
