Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

SLT is one of several solutions that have revolutionized Real-Time Trigger based replication to HANA. However given the challenges of modern day Enterprise requirements, how does this work in a system copy/refresh scenario without having to recreate the entire replication/initial load? A stringent search through marketplace or SCN does not yield much assistance. However broaden your search and you might come across something interesting.

The key to the above requirement lies in a non-standard solution that SAP has provided in note 1933605. This note was designed for a migration scenario, as you can see from the below excerpt.

“You are running SAP Landscape Transformation Replication Server for replicating data from a SAP system and you are planning to migrate the database of your source SAP system to another database vendor.

After the migration you would like to keep runing [sic] the replication of the tables without a need of performing new initial load.”

The main reason that such a solution is required is described in the note as per below excerpt.

“After the successful migration of your source SAP system to the new database from a different vendor, you would have the following status with your SLT replication:

- the SLT triggers will be not migrated, so they will not exist in your source system

- the SLT logging tables will be migrated but their structure ( the data type of field  IUUC_SEQUENCE ) will not corespond [sic] to the new database.“

Now how does this relate to a system copy/refresh procedure where the database and OS are probably the same? Think broadly and you will realize that in a migration or system copy scenario, you are transferring content from one database to another and a homogeneous copy is a subset of a heterogeneous copy. However in a homogeneous copy using database specific procedures, the triggers are copied along with the tables.

SAP therefore provided four non-standard programs in note 1933605

  1. ZMM_DEL_LOG_TAB – “The report will delete the old (obsolete) logging tables. Also will reset 'active trigger' flag in SLT, as the triggers in your source system are not active any longer.”
  2. ZMM_CREATE_LOGTAB_TRIGG – “The report will recreate the logging tables and the triggers. Also will set the corresponding flags into the SLT system.”
  3. ZMM_REDEFINE_OBJECTS – “The report will redefine and regenerate the replication migration objects, and the DDIC change of the logging tables will be taken into account. Additionaly [sic] the report will try to keep the old IDs of the migration objects in order that the latency information will be kept and the setup of any parelel [sic] replication will be kept.”
  4. ZMM_RECREATE_OBJECTS – “The report is only for the tables for which the migration objects couldn't be redefined with the report ZMM_REDEFINE_OBJECTS. In "LTRC transaction -> Data Transfer Monitor" the "generated" and "defined" flag are not set and the flag "failed" is set.”


So how do we get rid of the triggers after a homogeneous copy? SAP provides a standard transaction IUUC_REMOTE which can be used delete triggers as well as logging tables in a source system.


Now to put everything together in a procedure format we get the following – 

  1. System copy is complete, all post refresh activities are complete, proper RFC’s have been set and master job for target MT_ID is stopped in SLT server.
  2. Run IUUC_REMOTE in source system to delete all triggers. Delete all logging tables as well if you have a shared SLT server.
  3. If you have a shared SLT server do not run ZMM_DEL_LOG_TAB as this will destroy your source system replication. If separate SLT servers you can run ZMM_DEL_LOG_TAB, however this will not do much as the MT_ID of source will not exist in the target SLT server. In short this is only required if you perform a migration and continue replication with same MT_ID through the same SLT server.
  4. Run ZMM_CREATE_LOGTAB_TRIGG in the SLT system with target MT_ID as this should now recreate the triggers and logging tables and set corresponding flags.
  5. Run ZMM_REDEFINE_OBJECTS in the SLT system with target MT_ID and this should redefine all internal SLT objects with the recreated triggers and logging tables.
  6. Run ZMM_RECREATE_OBJECTS in the SLT system only if ZMM_REDEFINE_OBJECTS fails for certain objects/tables.
  7. If no issues occur then start the master job for target MT_ID and replication should continue without erasing the table contents in HANA.

The above steps can be adapted to almost any system copy/refresh scenario comprising SLT replication. The only drawback with this method is there can be data in the source system which does not exist in the target HANA database. However you can simply reload just that specific table from HANA studio and everything should be in sync. At least you don’t have to reload everything right?

Maybe in the future SAP might provide a standard procedure but for now maybe this can suffice.

--------Note from SAP------------------

The described way is possible and thank you to Sharan, but there is also now a guide available:

Resume Replication without initial load after System Refresh: https://scn.sap.com/docs/DOC-68026

24 Comments
Labels in this area