Operational Aspects of SLT Data Replication

After completing this lesson, you will be able to:
• Know how to manager structural changes on replicated tables
• Understand the Backup and Recovery Strategy
• Describe the concept of data volume management

Business Example

Software maintenance in the source system can affect tables in replication and care must be taken to ensure that replication can continue after maintenance events.
These structure changes (changes in key or non key fields in tables) must be identified (in the transport requests) manually, as there are no predictive or comparison tools between the source system and HANA database for this purpose.

General Procedure

-> Request transport owner to identify any dictionary change of replicated tables

-> Import transports in test system first to identify impact of replicated tables

-> Take any necessary actions

-> Resume the replication after maintenance or transport

When the replication process begins for a table, a database trigger is activated for that table. As soon as the database trigger is active, the data dictionary blocks any structural changes for that table. Therefore the table activation is cancelled if a trigger is active.

Also the transport containing structural changes to a table for which trigger is active will end with error.

Deleting DB triggers

To be able to activate structural changes in tables, database triggers need to be deactivated for relevant tables. SAP recommends to delete trigger by stopping the replication in HANA system.

If it is not possible to delete trigger in HANA studio, it can be deleted via transaction IUUC_REMOTE in source system or directly on database. If triggers are dropped in source system without data provisioning UI, replication should also be stopped via HANA studio afterwards for consistent table status.

Once the triggers are deleted, structural changes to tables can be transported and table can be activated.

For starting replication again, press REPLICATE button in HANA studio data provisioning UI

The LT replication server will drop the table in HANA system, creates it again with new structure and loads data again from the source system.

Reloading the table again ensures data consistency but may be critical if huge tables are adjusted. There is an alternative expert function to avoid the reload if some prerequisites are fulfilled.

Restart Replication – Expert mode

1. If table changes are executed during system downtime, and it is ensured that no user or program will change any data while triggers are not active, the replication can be resumed without repeating initial load
2. To resume replication of stopped table without repeating the initial load, the action M (activate delta recording) and Q (start replication without initial load) can be used.
3. As both of these actions are not available via data provisioning UI, the action have to be trigger via an insert in table RS_ORDER in the respective HANA schema
4. Activate delta recording trigger on source table (Action M)
5. INSERT INTO REPLICATION_TARGET.RS_ORDER VALUES (‘TABLE’,0,’M’)
6. continue with replication (without load) – Action Q
7. INSERT INTO REPLICATION_TARGET.RS_ORDER VALUES (‘TABLE’,0,’Q’)
8. Check the status of action M and Q in table RS_STATUS

Note: As M and Q are not available in Data Provisioning UI, you will get error in UI as long as last status is M or Q

Data in RS_STATUS table:

Status: O-> Scheduled

P -> In Process

X -> Executed

Action type M or Q changes to R (replication in process) once the first record is replicated.

Backup and recovery strategy – general recommendations from SAP

Backup your system landscape regularly to ensure that you can restore and recover system in case of outages or other failures.

You need to backup or restore each component and also handle cross system data dependencies.

You must ensure that backup storage is separate from normal storage location.

Below are some situations of failures

Source system goes down

In this case replication is stopped. Action need to be taken is to restart source system SLT, it will continue automatically where it stopped.

SLT system goes down

In this case replication stops. Action need to be takes is to restart SLT system and restart master job (via transaction LTR) to continue replication

SAP HANA system goes down

In this case also replication is stopped, SLT waits for HANA system to be available again. Action should be to restart HANA system. SLT will continue automatically at where it stopped.

If the source system or HANA system cannot be recovered, tables have to be dropped and loaded into the HANA system to ensure that both systems are in sync again. Therefore replication need to be stopped and started again for all the tables.

Data Volume Management for SLT

In source system

SLT related logging tables: The size of logging tables may increase. If replication is suspended for long time, or if there is system outage of source or target HANA system, the log table size will increase. You should monitor the table size carefully and take appropriate action. (logging table should be assigned to separated tablespace)

RFC logging: Since data replication from SAP source system is managed by RFC connection, related size of log files should be reviewed. Especially if performance improvements are implemented that will increase number of jobs, check if RFC related logging is critical.

In SLT system

There is no specific memory issue to be considered in SLT system since data records during replication process are handled in memory in SLT.

In case of source or target outages, the related log table will be filled.

To avoid unnecessary logging information, you can pause replication by stopping the schema related jobs.

SAP HANA system

Depending on number of tables that have status in replication (or initial load only) and growth rate of tables in source system, the size of HANA database will increase accordingly.

Note: Since HANA supports compression, the table size in HANA database may be different to source system. If the table size in HANA exceeds 2 billion records, you must split table by using available partition features.