Executing Replication Load

The image shows the process of starting and stopping data replication.

When you select a table to replicate, the following steps are executed:

• At the beginning, SLT creates or drops a table in the target SAP HANA database.
• Next, a logging table is created in the source system, followed by the creation of three database triggers on the application table:
  • One for inserts
  • One for deletes
  • One for updates
  Note

  If your source system runs on an SAP HANA database, four triggers are created. For more information, see SAP Note 1620618.

• Every change on the application table is now recorded in the logging table.

• Next, SLT starts to load the application table into the target.

• When the table is completely loaded into the target, SLT starts to work on the logging table. It processes all of the changes that have happened so far as well as any new changes that occur in the application table. This means that every replication contains an initial load or full load.

• The replication of data proceeds until you suspend or stop it.

The following definitions are important to avoid mistakes in handling SLT:

• Stopping a replication means that you stop the data transfer, and you also get rid of the triggers and logging table in the source system. Thus, no further changes are recorded. If you want to replicate the table at a later point in time again, you must start from scratch.

• Starting from scratch means that you must reinitialize the replication. This involves the following actions:

  • Creating or dropping the target table

  • Creating the logging table and triggers in the source system

  • Performing the initial load

  • Entering the replication phase

If, for example, your source or target system is down due to a maintenance event, you might want to prevent the SLT server from making RFC or database connection calls to this system. In this case, you might want to pause a replication. To do so, you can use the suspend functionality. Here, the data transfer from source to target is stopped or paused. Nevertheless, the triggers and logging table in the source system are still active and they record changes on the application table.

You can use the resume option to continue the data transfer again. SLT works on the backlog in the logging table. As soon as all data has been processed, it replicates changes in real time again.

The following figures outline the behavior of database triggers and logging tables.

You want to replicate an application table with two records. In the process of starting recording, database triggers and a logging table are created. For simplification reasons, assume that the replication is currently paused or suspended and that you are not processing any records in the logging table.

A new record with the ID 4712 is added to the application table. The INSERT trigger records this ID in the logging table.

An update on the record 4711 occurs (data field 2 is updated from 53 to 42). This update is recorded by the UPDATE trigger and is written into the logging table.

The data record with the ID 0815 is deleted from the application table. The DELETE trigger updates the logging table accordingly.

The following steps occur:

1. When replication resumes, the reader module is called by the SLT server. This retrieves information about unprocessed records in the logging table according to their sequence.

2. By using the application table key field values, the reader module accesses the application table and gets the complete data record.

3. Those records are then returned to the SLT server for further processing.

Note that SLT works on the logging table in portions. By default, up to 5,000 recorded changes are handled in such a portion (100 for cluster tables).

Once the data is successfully transferred to the target, the respective logging table entries are marked as processed. They are then deleted from the logging table. In the event of 1:N replication, the entry remains in the logging table until the last subscriber has successfully transferred the data.

In the transaction LTRC, open a configuration and, on the Table Overview tab, select Data Provisioning. There, enter the table that you want to replicate, and select Start Replication → Execute.

In transaction LTRC, on the Table Overview tab, the table is added with the current action: Replication (Initial Load). Once the initial load is complete, the current action changes to Replication.

In the Data Transfer Monitor tab, for the record in replication, the status always switches between In Process and Loaded. When it is In Process, it is checking if new data is in the logging table and the data is transferred. When it is Loaded, it means that currently no data was found that needs to be replicated.

To start the replication of a table in the reworked LTRC UI of our training landscape, follow the steps below.

In the transaction LTRC, open a replication and choose Data Provisioning, which can be found at the top of the screen. Enter the table that you want to replicate as Object Name. Select Analyze Actions.

Select Edit Action → Start Replication (Including Initial Load) → Confirm. Check the info provided on the table that you want to load and select Validate Actions. Be sure that the listed objects are consistent.

Select Schedule Actions.

In transaction LTRC, on the Participating Object tab, the table is added with the current action: Initial Load (Replication). Once the initial load is complete, the current action changes to Replication.

In the Details column, you can see that it is checking if new data is in the logging table.

You can check the structure of the logging table in the source system. To do this, use the table name specified in LTRC, on the Table Overview tab.

You can also view the trigger coding. If it is an ABAP source system, display the table ABAP dictionary object of the table (transaction SE11 or SE12). To find the database-dependent trigger coding, select Utilities → Database Object → Display. Alternatively, you can use the Expert Functions in transaction LTRC to show the trigger coding where available.

Starting from SAP Landscape Transformation Replication Server 3.0 SP04, a new change data capture (CDC) recording mechanism was introduced to facilitate the replication of data from CDS views as well as tables. This subscription-based CDC recording mechanism allows an unlimited number of subscribers for a table or a CDS view (unlike the current implementation of the CDC).

To check the structure of the logging tables in the source system, use the links specified in Display Object Details in LTRC (our reworked UI) on the Participating Objects tab.