Introducing Robust Data Transfer

Objective

After completing this lesson, you will be able to understand how to transfer data in a robust way.

Robust Transfer of Data

The image shows a robust data transfer between SAP source system, SAP LT Replication Server, and SAP HANA system.

Diagram of robust data transfer between SAP source system, SAP LT Replication Server, and SAP HANA system.

Note that captured data changes are not lost because of the temporary unavailability of a system. Any uncommitted data transfer is repeated until it is successfully committed to a source system.

The process is outlined in the figure. Records in the logging table are only marked as processed once the data to be transferred is successfully written to the target system.

Business Continuity Aspects

SituationConsequencesActions
Source system goes down.Replication is paused and SLT waits for source system to be available again.
  • Restart the source system.
  • SLT will continue from where it stopped.
SAP LT Replication Server goes down (or source system and SLT, if on the same stack).
  • Replication is paused.
  • Source continues to capture changes via DR Trigger in Logging Tables.
  • Restart SLT jobs.
  • Rework of collected changes.
SAP HANA system goes down.
  • Replication is paused.
  • SLT waits for HANA DB to be available.
  • Restart the HANA system.
  • SLT will continue from where it stopped.

The table outlines the diverse outage scenarios. As we have already discussed, no data will be lost.

If the source system goes down, recording of source system data changes is not affected because no data changes in the source system are missed while the source system is down.

While the source system is down, the source system tables will have the status Failed on the Participating Objects tab in transaction LTRC in the SAP LT Replication Server system. However, the SAP LT Replication Server system will periodically try to replicate data from the source system, and once the connection to the source system can be established again, the replication will continue as usual. To avoid error messages in the application log, all configurations can be deactivated until the source system is available again.

Manual Actions:

  • If an access plan calculation was in process for a table in the source system when the source system went down, stop and restart the relevant table; this will also restart the access plan calculation.
  • Deactivate all affected configurations to avoid errors in the application log.

If the SAP LT Replication Server system goes down, no data will be replicated to the target system. While the SAP LT Replication Server system is down, data changes will continue to be recorded in the source system as usual. Once the SAP LT Replication Server system is up and running again, the replication of data to the target system will resume automatically.

If the target system goes down, no data can be written to the target system. In the SAP LT Replication Server system, on the Participating Objects tab in transaction LTRC, the status of the tables will be Failed. Once the target system is up and running again, the transfer of data will continue automatically. To avoid error messages in the application log, all configurations can be deactivated until the target system is available again (you can do this in transaction LTRC).

Manual Actions:

  • To avoid increasing the size of the logging tables, stop the relevant tables and repeat the initial load once the target system is up and running again.
  • Deactivate all affected configurations to avoid errors in the application log.

When you are backing up systems, remember that a backup of the source, the SLT, and SAP HANA system (at the same timestamp) is required. If the source system, or the SAP HANA system, cannot be fully recovered to the same point in time, you must drop tables in SAP HANA and reload them into the SAP HANA system. This ensures data consistency between both systems.

This situation can be avoided by applying the replication logging feature, as long as the point-in-time recovery falls into the configured data retention period.

Replication logging is explained in detail in another unit of this course.

Note

For more information, see the Unscheduled Downtime- Recovery Guide.