cancel
Showing results for 
Search instead for 
Did you mean: 

SLT Replication of BSIS table TIME_OUT

Former Member
0 Kudos

I'm currently working on a SAP HANA project where SLT is used to replicate various SAP ECC table to SAP HANA. I have managed to succesfully replicate various tables where the target table structure is changed and filters are applied to filter the data which is inserted into SAP HANA. Unfortunately I'm bumping into an issue with a large table called BSIS. The table contains approx. 115 mln rows and generates a TIME_OUT. Other tables (largest 23. mln rows) have been replicated succesfully.

Current behaviour is that during a period of 2400 seconds a dialog process is busy doing a sequential read on the BSIS table. However after 40 min. it generates a TIME_OUT an start all over again. Funny thing is that initially the table started to replicate with about 220.000 rows already replicated to SAP HANA. After that the process is looping in a 40 min. procedure of reading, generating a TIME_OUT and starting all over again.

Does anybody have an idea what we could investigate to troubleshoot? Please let me know which further information should be added to the discussion to help troubleshoot the issue. SAP HANA is running op SPS05 rev. 51. DMIS component is 2011 SP3. All necessary correction notes have been submitted (although the ones on ECC have been submitted after the initial load for BSIS has started).

I have opened an OSS message but no response from SAP yet ;-(

Thanks for your reply!

With kind regards,

Martijn van Foeken

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Martijn

One question that may help to point in the right direction, if I may ?

Is SLT running on a separate server or is your ECC system also your SLT system ?

It may be useful to share some information on your schema settings for the replication as entered in LTR, such as how many data transfer jobs and initial load jobs do you have configured ?

What status does table BSIS have in the Data Provisioning screen in HANA Studio ?

To troubleshoot, you may be able to get some direct feedback as to why the issues occur by looking at either transaction MWBMON or IUUC_SYNC_MON ( both SLT transactions ).

Also, take a look at the system log, in both systems if SLT is separate to ECC.

If you know a dialog work process starts to process the replication, but then gives you a TIME_OUT, have a look at the developer trace for the work process. The dump, visible in ST22, that occurs when you have the TIME_OUT may also help.

You may need to delete the original load of BSIS in HANA and start again, given that corrections have been applied to SLT after the initial load.

Is it possible the issue is in HANA ?

Take a look at the Administrator perspective in HANA Studio and check all alerts.

I've not seen a TIME_OUT in ECC for any of our current replication scenarios, but I hope this feedback helps you to diagnose the issue.

regards

Simon.

Former Member
0 Kudos

Hi Simon,

First of all thanks for your reply! I the meantime we decided to not wait for the response from SAP on the OSS message but continue with some other options.

After trying a few small tables which all replicated perfectly we started to load another 'big' table with 58 mln. records, the BSAS table. So far this is running perfectly.

For the first time however we noticed that the BSIS table went into error.

To be complete let me answer your questions and provide additional information:

-----------------------

One question that may help to point in the right direction, if I may ?

Is SLT running on a separate server or is your ECC system also your SLT system ?

It is a separate system

It may be useful to share some information on your schema settings for the replication as entered in LTR, such as how many data transfer jobs and initial load jobs do you have configured ?

2 initial load job and 10 data jobs

What status does table BSIS have in the Data Provisioning screen in HANA Studio ?

On load for a long time but today it switched to load/error

To troubleshoot, you may be able to get some direct feedback as to why the issues occur by looking at either
transaction MWBMON or IUUC_SYNC_MON ( both SLT transactions ).

Is there somewhere some explanation about these transactions? I knew them already but can't find much information about them

Also, take a look at the system log, in both systems if SLT is separate to ECC.

No errors on the SLT system, only on the ECC system. And the only error there is explainable (TIME_OUT) somehow the data load takes longer then 40 minutes. And that is on the acceptance system the limit for a proces to take use of a dialog process. 40 minutes however, is already an extremely big value for a timeout so the question is why the data load does take so long.

If you know a dialog work process starts to process the replication, but then gives you a TIME_OUT, have a look at the developer trace for the work process. The dump, visible in ST22, that occurs when you have the TIME_OUT may also help.

You may need to delete the original load of BSIS in HANA and start again, given that corrections have been applied to SLT after the initial load.

What do you mean by this? I can empty the BSIS table of course in Hana but that won't cancel the data
load job itself. And as long as the job runs I cannot kill it to restart it.

Is it possible the issue is in HANA ?

Everything is possible 😉 but I doubt it, the hana system's CPU load is 0 and also the SLT system does not seem to retrieve any data of this specific table. Other tables were replicated without issues by the way but BSIS table is the biggest we tried so far. Problem seems to be that the data load runs in a dialog work process instead of a BTC and that it takes longer then 40 minutes

Take a look at the Administrator perspective in HANA Studio and check all alerts.

So far I haven't notices any issues in Hana itself

I've not seen a TIME_OUT in ECC for any of our current replication scenarios, but I hope this feedback helps you to diagnose the issue.

What is the largest table that you replicated to hana?

-----------------------

Thanks for your reply!

With kind regards,

Martijn van Foeken

Former Member
0 Kudos

Hi Martijn

Thanks for spending time to reply.

Our largest tables, in a sandbox environment using an ECC system refreshed from a production system, are over 800million records.

I've spoken to my functional expert as regards your scenario with BSIS.

He asked the question have tables BKPF and BSEG also been replicated to HANA ?

Following on from my earlier questions, probably the most important question to ask, I think, is about the reading type you have used for BSIS in SLT and whether you have anything in IUUC_PERF_OPTION ?

Also, do you have filtering enabled for your replication ?

If so, where is it enabled ? On the ECC system or on the SLT server ?

If the filtering is set in ECC, then this may be the cause of your TIME_OUT in the ECC system.

Sorry to answer questions with questions - we may come to a solution between us

Thanks

Simon.

Former Member
0 Kudos

Dear Simon,

Thanks for your reply, I'm a colleague of Martijn and working together on this issue so I will try to answer your questions.

have tables BKPF and BSEG also been replicated to HANA ?

No we did not replicate those, but we also tried the BSIS table from a smaller sandbox (which contains only 600.000 entries and there it synced fine (also without those two tables).

whether you have anything in IUUC_PERF_OPTION?

No initially not, however, the table BSAS contains 58.000.000 (which is less then 115.000.000 ofcourse) and this one synced (also without this option) fine in a few hours. As I understood the 'normal' replication method will already replicate only 10.000 records per time and with the IUUC_PERF_OPTION you would be able to increase the performance of the initial load by breaking the whole table in smaller sizes and running multiple replication jobs together. In our case it is not an performance problem but it occupies an dialog process for more then 40 minutes (which is our time out for dialog work processes) and then gives a TIME_OUT shortdump (so it never sends records at all). I monitored the replication of the BSAS table and there it only occupied a dialog work process on ECC for 20 seconds after which it started a new process in another dialog work process. So that is a big difference and looks like the BSAS table was indeed send in parts of 10.000 records and it seems that it tries to send the whole BSIS table at once (otherwise I cannot explain why it occupies an work process on ECC for more then 40 minutes).

do you have filtering enabled for your replication?

yes we use filtering on the SLT in transaction 'iuuc_repl_content'. Under "IUUC REPL TABSTG" we adjusted the table structure to exclude some fields which we do not need. All fields part of the key are included in the replication though. And under the tab "IUUC ASS RUL MAP" we added an line of code filter for the "beginning of record" event. The line of code we use is 'IF <WA_R_BSAS>-BUDAT LE '20100930'. SKIP_RECORD. ENDIF.' but both filters are also used on the BSAS table.

For the BSAS table this means that only 17.000.000 records of the 58.000.000 records are replicated (without issues) and for the BSIS it means that it should only replicate 37.000.000 of the 115.000.000 records. I don't know if Martijn mentioned it before but the BSIS table did replicate 200.000 records before the issues started.

We do have on important question, don't know if you have an answer for this?

Currently the BSIS table is still running an initial load. This will never finish since no data is send from ECC to SLT (all jobs end in a TIME_OUT shortdump). We like to try to add the 'IUUC_PERF_OPTION' option however, in order to do this we need to stop the load. It is easy to stop (or suspend) an existing replication from the hana studio but you don't have the stop or suspend options for tables which are on the initial load. So how can we reset this table replication so that it uses the new configuration?

Kind Regards,

Nico van der Linden

Former Member
0 Kudos

Hi Nico,

You could try (at your own risk) via function module IUUC_REPL_STOP_REPLICATION direct in the SLT system, what I am not sure about is whether the table has to be in the 'replication' status in order for this to work. However, the safest way would be to open a message with SAP as they can stop the jobs for you.

I assume you are trying to create some open/cleared items queries given that you are loading the BSIS tables...perhaps a better way for HANA is to load BKPF and BSEG. You will need to use a different reading type for BSEG.

Good luck

Kris

Former Member
0 Kudos

Dear Kris,

thanks for your answer. It is good to know this function module, we do have an OSS message (with priority high) but it takes ages before SAP replies on them but we will wait a little longer and otherwise we can try this function module to see if the jobs stop.

We will have an look at the other tables but it was on request of the business that table BSIS was replicated.

However, if anyone knows what the reason could be that the ECC dialog work process is occuppied for more then 40 minutes then I would be very happy. I hope that it is solved when we adjust IUUC_PERF_OPTION (as soon as our job is stopped), but I doubt it a bit since we replicated other big tables without issues.

Thank you all for your replies so far.

Kind Regards,

Nico

Former Member
0 Kudos

Hi Nico,

Can you check the reading type for BSIS...reading type 2 tries to read the whole table in one portion...just a guess that could explain the TIME_OUT? Wlse wait for the SLT wizards to reply 🙂

Thanks

Kris

Former Member
0 Kudos

Hi Kris (and others),

we are going to try to replicate this table again with a different reading type. But we did get a reply from SAP in how to stop an running Initial Load.

You have to stop the master job in transaction LTR, then in the hana studio you execute the SQL statement

insert into <schema>."RS_ORDER" values('<SID>','<hostname>','<tablename>',0,'C');

The values for <SID> and <hostname> are the ones that are displayed in the data provisioning perspective in the HANA studio. The hostname is the name of the SAP instance of the source system, usually something like <hostname>_<SID>_<system number>

depending on your DMIS version you might have to use the SQL statement "insert into <schema>."RS_ORDER" values('<SID>','<hostname>','<tablename>',0,'C','','','');"

after you restart the master job the table replication will be stopped and you can restart the initial load. The RS_ORDER table will be empty again after the restart of the master job.

Hopefully the replication problem will be solved as well now for us but I will let you know later. I just wanted to share this part already since it is not very good documented yet.

Kind Regards,

Nico...

Former Member
0 Kudos

Hi Nico,

Were you able to solve this issue with BSIS ?

It would be great, if you can share this information with us.

Thanks & regards,

Jomy

Former Member
0 Kudos

Hi Jormy,

yes we fixed it eventually by using a different reading type for this table (4 if I remember correctly).

Kind Regards,

Nico van der Linden

Former Member
0 Kudos

Thanks Nico!!