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 –
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 –
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
8 | |
7 | |
6 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |