SAP for Utilities Discussions
Connect with fellow SAP users to share best practices, troubleshoot challenges, and collaborate on building a sustainable energy future. Join the discussion.
cancel
Showing results for 
Search instead for 
Did you mean: 

DEVICE data load terminating in background (EMIGALL)

dsbadwal
Explorer
0 Kudos

Hello Conversion experts,

I come up with an exceptional issue which I never faced before.

While migrating DEVICE data through distributive import run in EMIGALL it terminates in the background after sometime. We have checked the active processes in SM66 and lock entries too and found some dialog WP on "Hold" status with RFC responses as description.

Lock entries also getting created on EQUI table, but we are not able to figure out the reason behind the termination happening in background.

Could anyone help us on this.

More details:

data count : 1,200,000 approx

File size: 6000 (data objects)

4 App Servers : using 8-10 WP out of 40 Background WP initially then increase accordingly.

Thanks,

Davinder

1 ACCEPTED SOLUTION

former_member227287
Active Participant
0 Kudos

Hi Davinder,

Can you please share the ST22 Screenshot .

Also just check in the system in which you are loading the data , if someone has reset the number range for Equipment No, resulting in Duplicate equipment no and thereby terminating the background job.

Regards,

Chandandeep.

View solution in original post

5 REPLIES 5

former_member227287
Active Participant
0 Kudos

Hi Davinder,

Can you please share the ST22 Screenshot .

Also just check in the system in which you are loading the data , if someone has reset the number range for Equipment No, resulting in Duplicate equipment no and thereby terminating the background job.

Regards,

Chandandeep.

0 Kudos

Hi Chandandeep,

Thanks for the reply.

Actually it doesn't end up into an ABAP dump, it simply fails to distribute the master job on other app servers and terminates.

For the second possibility of duplicate number range I need to get back to you with a check.

Thanks,

Davinder

0 Kudos

One more thing Chandandeep, I want to share.

It works fine If I put up the whole load on 1 dedicated app server instead of distributing on 4.

Preferably I use 20-30 WP of 1 app server keeping other 3 as zero and file size upto 15K to 20K.

This hit and trial method works but takes lot of time, but the good thing is it won't terminate and do load the entire set of data in a single go.

0 Kudos

Hi Davinder,

This looks more like BASIS issue than Migration issues. Check with BASIS to monitor the system for CPU over consumption & high memory usage, resulting in process termination.

Is this happening for only DEVICE migration object or for all?

Regards,

Chandandeep.

dsbadwal
Explorer
0 Kudos

Hi Chandandeep,

Yes, it happens only with DEVICE and even BASIS has no clue yet.

So right now load happens in 4-5 restart iterations after termination in background.

We usually wait for all child jobs to complete ( in SM66) and then clear the lock entries (on EQUI) and restart the job with different split file names or by deleting the split files from AL11.

Important things:

1. Update work processes are getting fully utilized and ends up with "ON HOLD".

2. RFC calls are being made through dialog work processes parallel to data load on background WP.

Thanks,

Davinder