SLT and HANA deleting archived data

[justin_molenaur2]

From the SLT Operations Guide, section 5.2 I can see the following statement

5.2 Archiving Data in Source Systems

The trigger-based replication also considers the deletion in source tables by archive activities (since it is not possible to distinguish on the database level between delete actions cause by archiving versus regular deletion of data records). As a consequence, SAP LT Replication Server will also replicate archiving activities as delete actions in the SAP HANA database.

In a typical standalone/sidecar implementation of SAP HANA, I would assume that in most cases this is not favorable behavior or a desired function. In typical DW/DataMart implementations, the data should be persisted in the target even after the source system data may have been archived. I can refer back to how BW operates in this caes - any new/changed data is extracted to BW, but any archiving operations do not affect the already extracted data in the target system.

I know there is functionality available to load archived data into HANA, but that would seem like a troublsome method to 'put the pieces back together' and get a wholistic picture of all the historical data (online data + archived objects) and would present some interesting challenges in the target (HANA).

Is there any way to disable the functionality to replicate deleted data due to archiving? Is there anyone with some experience navigating around this hurdle in a standalone/sidecar scenario that can shed some light as to how they handled this?

Thanks,

Justin

[former_member182843]

Hi Tobias,

Option 3 (having a dedicated archiving server) seems an interesting option. However it's not clear to us how to implement it. Say we have 2 ECC servers to simplifies this: one for regular activities and one for archiving. But we have only one SLT server, so how would we distinguish in the ABAP rule the archiving server? Is there any easy way to do that? Could you please elaborate?

We have severals BI projects impacted by archiving. I am sure many customers are facing this situation. Do you have any news on the long-term kernel standard solution?

Thanks a lot,

Christian

[Former Member]

Christian,

We are working with SAP on option 3 with SAP AGS support for a while and facing some challenges on dedicated archiving server in ECC, we believe without some enhancement at kernel level, there has no garantee you can isolate the application server only run archiving jobs.

We asked SAP AGS support submit the kernel enhancement requirment to SAP development team, but there has no date come back to us yet on when it will available. I can let you know once we have date on that.

Cheers,

Xiaogang.

[former_member182843]

Thanks Xiaogang for the answer. Could you elaborate a little bit on the challenges you are facing to isolate the archiving server? Is this mainly to prevent users to log to that server, or it's more technical issues towards replication with the tranformation on the SLT?

Christian

[sam_venkat]

Hi, could you elaborate on the challenges you are facing with respect to app server isolation for archiving ? thanks

-Sam

[Former Member]

To isolate a applicaiton server, not only for limite dialog user logon in, we have to consider all work process type like BTC/UPD/RFC....There has no existing functional within SAP can do that, so SAP ask us use various function for other purpose which can help isolate application work process, e.g. we set archiving job as A class and then use security to control the user who can run A class job, we use logon group for user login and exclude that application server from all logon group except the archive logon group we created just for run archive job, it's complicate and sometime has side effect, we put all SAP recommendations in our system and run for months, we monitoring the system and find out from time to time there has user/process running on dedicated application server which is not suppose to be there, no one from SAP can explain why. The conclusion is existing functionality can't meeting this requirement and kernel change is required.

However, recently SAP come back with new solution which doesn't require isolate application server, instead it user based, which is much better option for us, it does has some limitation as of now e.g. only availalbe for Oralce database by now. We are testing this new solution and so far result is positive.

Cheers,

Xiaogang.

[former_member193200]

Hi Xiaogang,

we basically have the same situation. The isolated application server wasn't a valid solution for us. But I would be really interested in the solution based on a certain user. Could you explain a little bit how this solution will work and what's the technical basis for that.

Cheers

Dirk

[former_member117942]

Hi Xiaogang,

we have tested solution with dedicated application server but it is complicated and it seems to have some side effects as described in your email.

Could you give us more details about this new SAP solution for replicating data without take care of archiving deletion?

Regards

Maurizio

[Former Member]

Hello,

to "isolate" the application server dedicated to the archiving job we made this:

- create an jib server group as per note 786412 - Determining execution server of jobs w/o target server    is this group we DON'T insert the AS dedicated to the archiving

- in the profile of the AS dedicated to the archiving we set the parameter rdisp/tm_max_no=0 so no DIA, RFC and login is possible on that AS http://help.sap.com/saphelp_nw70/helpdata/EN/af/d8e6714c04264a81951c7cedf4cf4c/content.htm

- in the archiving customizing we set to use the archiving AS

In this way the AS is totaly dedicated to the archiving processes.

Regards

[sam_venkat]

Does this mean setting "rdisp/tm_max_no to 0" restricts only GUI, RFC, or HTTP logins but    BTC are not impacted?  In other words archiving jobs can execute fine. Does this also prevent UPD from other instances executing on the Archiving AS instance?  Thanks

-Sam

[Former Member]

Does this mean setting "rdisp/tm_max_no to 0" restricts only GUI, RFC, or HTTP logins but    BTC are not impacted? --> yes

In other words archiving jobs can execute fine. Does this also prevent UPD from other instances executing on the Archiving AS instance? --> the AS of archiving have not UPD procecesses, only DIA (mandatory to start the AS) and BTC (to run the archiving processes)

[sam_venkat]

Hi Matteo, thanks for your response.  Does it mean archiving jobs do not required UPD workprocess?  Just wanted to make sure.

[Former Member]

Hi,

archiving jobs need UPD workprocess, but these workprocess must not run on the AS where the archiving is running, archiving workprocess use UPD workprocess of the other AS.

Please mark the answer as correct or usefull.

[Former Member]

Hi Dirk,

In a nutshell, we modify the database trigger generated for SLT replication by passing the user name which we used in ECC to run archiving job, all deletion from this user we consider as archiving deletion which means data will delete in ECC but we will keep in HANA.

It's custom solution SAP build for us and they say they may include this in future DMIS package.

Hope this help.

Xiaogang.

[Former Member]

Hi Maurizio

The new solution is user based, basically, we modified the database trigger for those tables are archived in ECC, when deletion is made by archive user, then deletion will treat as archive deletion and this information will pass to SLT, SLT will not delete the data in HANA if it's archive deletion.

Cheers,

Xiaogang.

[former_member204789]

Hi Xiaogang

Can you please share more details about how did you change database trigger to get the user id ?

Kind Regards

Kamaljit Vilkhoo

[former_member367786]

Hi Xiaogang,

may you post an update here about the option 4), what you described above regarding SAP solution on modifying the trigger, which skips delete requests from the dedicated archiving user, so deletions by archiving won't be replicated to target HANA?

We are about to implement option 3), but, looks, it does not work really well, also, by your message option 4) is already available and think a real sophisticated, reliable one.

Thanks and best regards,

Zsolt

[Former Member]

Hi Zsolt,

I suggest you contact SAP AGS support and ask them help to implement this solution for you. This is what we did due to procedure is not straight forward. It required configuration change and modify DB trigger in ECC, create new ABAP code in SLT for each table and this has to be done table by table. SLT DMIS SP08 make this procedure a little simple but still require lots manual changes, user based solution also has limitation which you can only allow ONE user in ECC run archiving job.

Thanks,

Xiaogang