EMIGALL Distributed Import Job for BP is getting cancelled in background

[Former Member]

Hi,

When I'm restarting Distributed import and it's getting cancelled after some time with system error as "internal lock table overflow".

I checked SM12 (while job was running) it's showing 14,000 - 15,000 locks on table BUT000, even though EMIGALL is not updating that table as it's rerun of the old job. (Old job been cancelled due to network issue.).

Can anybody please help me to understand why it's happening?

Thanks in advance,

Sagar

[Former Member · Accepted solution]

Hi Sagar,

I assume that not the master job but the slave sjobs cancels with the error 'lock table overflow'. Is this correct?

How many jobs you are running in parallel? How many BP each slave job has to process per (split) import file?

How many of them (percentage) are really re-processed and how many have already been loaded? From the re-processed ones: how many fail again?

Cheers,

Fritz

[Former Member]

Hi Fritz,

I think I got the solution for my problem.

I found it in Migration Perfomance Cookbook.

Notes 400745 will solve the problem I think.

Thanks Anyways,

By the way It's the master job that's faling, I can see the error in System log saying Lock table overflow..!!

I'm running with 22 WP on first run

then for 2nd reduced it to 18.

[Former Member]

Hi Sagar,

I'd assume that the cancellation of the master job is just an indication that something goes wrong with the slave jobs. It would be good if you could answer my questions above to get a better idea what's happening in your system.

Kind regards,

Fritz

[Former Member]

Hi Fritz,

Please find below answers to your questions:

I assume that not the master job but the slave sjobs cancels with the error 'lock table overflow'. Is this correct?

No it's master job that get cancelled.

How many jobs you are running in parallel?

18

How many BP each slave job has to process per (split) import file?

total 1.5 millinon records divided in 15,000 per file

How many of them (percentage) are really re-processed and how many have already been loaded?

1.2 million are uploaded and job get cancelled

From the re-processed ones: how many fail again?

when I "restart" the Import, none get uploaded as job is getting cancelled before reaching to the state at which first time the batch get cancelled.

I hope that might help you.

Thanks for your help and time.

Sagar

[Former Member]

Firtz,

File size was 5000 not 15000.

[Former Member]

Hi Sagar,

I think I can explain what happened in your system:

During data migration the application encountered many errors and does not release the locks immediately. Remember: it is not the slave jobs that creates locks but the called application (through the service functio module). If the application enncounters an error (also when the business object cannot be locked due to a lock table overflow) it returns the error and the load program writes it to the error log. The saved error message is not always directly related to the lock table overflow situation. Often it is saying: object already locked by user xxx).

The master jobs uses also locks to block the configuration of its profile against concurrent access (exclusive access). If a user blocks the profile temporarily during an update of the profile, the master job waits until the update operation finishes. This last usually only very few ms. If the master encounteres a 'lock table overflow' situation it cancels - as designed be the developer.

The simple solution is that you should avoid a lock table overflow situation and/or that the lock table must not be too small.

Sagar, I might also be that you find also the error 'lock table overflow' in the system log. Please check.

Kind regards,

Fritz

[Former Member]

Thanks Fritz,

Thant means I need apply 4000745, I've already done that though.

[Former Member]

Sagar,

Well, the note 4000745 fights the symptoms. Ideally you should resolve the data problems that leads to the rejected data objects - or increase the lock table ... 🐵

Cheers,

Fritz