Lock table Overflow as the file size is 50 MB BW side.

[former_member190358]

Hello Everyone,

I have a XML idoc file as input which is usually more then 50MB in size.

Usually, i am getting Lock table overflow at Receiver BW side . This error is pointing to Inbound_Asynchronous_Idoc.

i have tried dividing the Input XML idoc file into small group by handling them in chunk mode of sender communication channel.

However, since its TRFC , so if it gets processed in PI but at outbound if there is an Lock table overflow error, then it fails.

I have tried to process the 50 MB of file in parts by processing 5 MB at one point of time. but does this mean that BW also process data in parts or it gets entire 50 MB to process at one stretch.

Since the input is IDOC XML so i was not able to make use of Record Set per message. so i am making use of chunk mode.

AM i doing correctly ?

Regards,

Ravi

[rajasekhar_reddy14]

If you are not losing any data and BW Team not complaining any data lose then you are following correct approach.

[MichalKrawczyk]

hi,

have you tried changing parameter: enque/table_size ?

as per:

http://help.sap.com/SAPHELP_NW04S/helpdata/en/d3/43d2416d9c1c7be10000000a1550b0/content.htm

this is a standard thing to be changed in such conditions...

let me know if this worked,

Regards,

Michal Krawczyk

[former_member190358]

Hi MIchael,

Right now the IDOC XML files could range from 20 MB to 80 MB as well.

However, to check the SM12, i am not authorized to do so . Last time when i checked the en queue/table_size then it was close to 50000.

i am not sure if we can change or increase this , but i just have one simple question, that i want to divide this input XML file in 5 MB so that there will be 10 TRFC calls and BW will be able to handle this size.

Infact we could process 25 MB without any problem. its only problem when the size is more than that.

So how to achieve the solution without increasing the table size .

Regards, Ravi

[former_member181962]

Hi Ravi,

Is the chunk mode solution not working?

If not, one solution would be to ask the sender system to send multiple files instead of one big File.

Other option would be to have a mapping which would split the input message into smaller chunks, without impacting the message structure.

Best Regards,

Ravi

[former_member190358]

Hi Ravi Kanth,

Could you please tell me how to design a maping which would divide the data in chunks and then send to BW system for processing

My requirement is very simple that since BW cannot handle 50000 idocs in one TRFC calls, so i have to divide the input Idoc XML file into small pieces so that we could avois LOCK TABLE OVERFLOW error on BW side.

Regards,

Ravi

[former_member181962]

Check this blog:

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3765

This gives an idea of splitting a message into multiple messages.

Best Regards,

Ravikanth Talagana

[former_member190358]

Hello Everyone,

We have decided to use BPM to divide the input IDOC XML file into small pieces and then process it .

DO you think this approach is going to work ?

Regards,

Ravi

[former_member190358]

Hi Ravikanth,

If i make use of the below logic as mentioned in the link that you provided, then do i have to remove the chunk mode from communication channel .?

Secondly, mine is a SLSFCT idoc XSD that i am using here as source and target as well.

The hirearchy becomes like this after implementing the logic mentioned in link:

Messages

Message1

Z1ZBSD_SLSFCT01

IDOC

BEGIN

EDI_DC40

For Messages and MEssages1 there is no mapping at target side.

For Z1ZBSD_SLSFCT01 its 1..1 in source and 0..unbounded in target.

For IDOC its mapped to constant and Begin to constant with value 1 .

And then EDIDC to source and target are mapped to each other with occurrence of 1..1.

Is there some thing wrong that i am doing . because after this again the files are not getting divided

Regards

[former_member4224]

The lock table overflow occurs due a high requests of locks to enqueue table.

To avoid this kind of error you can work in two ways:

1. Increase the lock table size with parameter enqueue/table_size. There is no problem to increase the table until 100Mb.

I do not recommend to increase to a highest size because this can lead to performances issues.

If you still getting the overflow with a table size of 100Mb, you should follow the item 2.

2. Improve the application logic to decrease the number of locks requested. If I understand this is what you are doing.

Clébio

[former_member190358]

Hello Everyone,

i have designed the split first and then i used BPM and its working fine.

Thanks very much