Checking Database Triggers

The downtime-optimized conversion approach migrates and converts application data already during uptime. As the table content is potentially changed by end user activity after the initial migration and conversion, those changes have to be considered by Software Update Manager.

Therefore, the Change Control and Replay (CRR) technology is built into Software Update Manager, which is based on database triggers. Database triggers define actions that are executed when the corresponding database table is changed. The database trigger will write respective information into trigger log tables, that allow a later replication of the changes (Delta Replication) to the target.

When Software Update Manager processes an entry in a trigger log table, this is recorded in a corresponding trigger log history table. Both, logging tables and logging table history tables can be identified by their prefix:

The entries in the logging table store only one entry per key, so if a new object is created and later changed, only the key of the change is stored. This approach is called Unified Key Replication (UKR) and ensures that the growth of the tables is limited to a minimum.

Effectively, each table has more than one trigger to cover all SQL statements such as INSERT, UPDATE or DELETE. Below is an example of an INSERT-Trigger on table MARA, a table that is affected by the new data model of SAP S/4HANA. The example shows trigger /1CRR/TR00017043_I, the corresponding logging table is /1CRR/LT00017043, the log table history can be found in /1CRR/LTH00017043.

To see the triggers in SAP GUI, call transaction SE14, specify a table name and use the menu Extras → Database Object → Display and scroll down to the trigger section.

To check the content of logging tables or log table history tables, SQL can be utilized, for example from transaction DBACOCKPIT. Please note that this is executed in on the original instance and not on shadow or temporary instance.