update processes are alwyas be hanging

[Former Member]

Dears,

1. In T-code SM12 that I checked the Maximum number of Lock Entries is 18218 and Maximum Fill level is also 18218, the parameter "enque/table_size" is defualt value 32768, I think it's too small and it maybe cause the update processes are all hanging,
I want to adjust it more bigger, could you please give me a suggesting value ?

2. We increased two Dialog Instance on July and the issue(update work processes are always be hanging) happened from Augest 1st, I checked the DB parameter 'sessions' value is 2000 and 'processes' value is 1000, do we need to increase the value ?

Thanks,
Michael

[divyanshu_srivastava3]

Hi Michael,

enque/table_size - This parameters defines the sizes in MB and you have 32 MB defined which will there in main memory. So, don't get confused with the number of entries in SM12.

If you have an overflow of lock tables, check your update server is working correctly. If it's not working correctly then lock entries will grow quickly.

If update is fine, then increase the size of this parameter.

Regards,

[alwina_enns]

Hello Divyanshu,

what do you think which numbers in SM12 are confusing? The statistics in SM12 show you exactly, how many entries can contain the enqueue table and if this level is reached. This is very clear and not confusing...

Regards, Alwina

[divyanshu_srivastava3]

Hi Alwina,

"The value of parameter and the entries in SM12 - don't get confused with that "

That is what I wanted to say.

Regards,

[divyanshu_srivastava3]

Let me re-frame.

The parameter specifies the size in "32768 KB" or you can say 32MB.

Now, I think the user got confused with this value and the no. of locks seen in SM12.

So, I was clearing on that.

Regards,

[alwina_enns]

Hello Divyanshu,

enqueue statistics in SM12 looks like this (from our old test system, where nothing is running):

Enqueue Operations 3300681

rejected 27739

Error occured 0

Dequeue Operations 2651372

Error occured 0

Dequeue All Operations 2407335

Cleanup Operations 1

Backup Operations 7

Read Operations 50681

Compress Operations 0

Verify Operations 0

Records written 3617

to the backup file 14

Maximum Number of Lock Owners 3603

Maximum Fill level 7

Current Fill Level 0

Maximum Number of Lock Arguments 3603

Maximum Fill level 26

Current Fill Level 0

Maximum Number of Lock Entries 3603

Maximum Fill level 26

Current Fill Level 0

Update; Fill Level at Maximum 1

Current Fill Level 0

Time in Lock Table /Seconds 132.817572s

Wait for Lock Table /Seconds 15.275528s

Time in Lock Server /Seconds 110.441566s

"Maximum Number of Lock Entries 3603" show you, how many locks can be set in the enqueue table. And since the last system restart in our table there were only 26 locks at the same time (Maximum Fill level). If the both statistics show the same number, then this is a problem, it was an overflow of enqueue table.

Regards, Alwina

[alwina_enns]

Hello Divyanshu,

but in the statistics in SM12 you see the maximum number of the locks, which can be set. This is useful for example in the case, when you change the value for enque/table_size and you need to be sure, that the new value took effect.

Regards, Alwina

[divyanshu_srivastava3]

That is good.. my point was to explain the size(parameter) and number, and when and where to look. .

[alwina_enns]

🙂 but their system has already a problem with the enqueue table, and Michael has recongnized it. This enqueue table overflow should be solved first, the system cannot work correctly, if it cannot set locks, and after that the issue with the hanging update should be analysed further (if it will still persists)

[Former Member]

HI Srivastava,

There is always a Transaction will generated many update work processes,

and sometime the work processes will be hanging for a long time but still could be finished.

And every time only this Transaction's update work processes will be hanging and occupied almost all the update work processes, other Transaction's update is normal.

But the strange point is that we cannot reproduce this issue in the Test system with the same Transaction to run with the same condition.

Thanks,

Michael

[Former Member]

Hi Alwina,

I checked this enqueue table overflow is due to Transacion run with the incorrect conditions by the end users.

The hanging update was by another Transaction, and it alsmost happened everyday,

only this Transaction's update will be hanging, others are all normal,

But we cannot reproduce this issue with same the Transaction in the Quality system,

so it's real very strange.

So could you please tell me which sides I need to analyze for further ?

Thanks,

Michael

[alwina_enns]

Hello Michael,

at which action and at which program the update work processes are hanging? Could you please share a screenshot about SM50?

Thanks and regards, Alwina

[Sriram2009]

Hi Michael

1. When the update process getting hang what is the status of your database & CI instance & is this any issue on the network connection?

2. Kindly check the SAP link about the update process

Update Statuses - Updates in the SAP System (BC-CST-UP) - SAP Library

Regards

SS

[willi_eimler]

Hi Michael,

you should analyze if there is a process that causes the overflow of the enqueue table. For example deleting the sap mails can cause this overflow. You can get a list of the last 5 overflows by entering the string #01_002 in every field of transaction SM12 (in Field client you have to enter only #01).

Normally  a enqueue table is not configured to small. In most cases it is a bad process causing the overflow.

Best regards
Willi Eimler

[alwina_enns]

Hello Michael,

if you see "Maximum number of Lock Entries is 18218 and Maximum Fill level is also 18218", then either the value for enque/table_size needs to be increased or an application cannot set locks correctly. There are no recommendation on this parameter. You can increase it step by step, you can double the value first, and monitor the system, how behavour has changed. A rule of thumb

would be to achive the maximum fill level of the enqueue table stays bellow the 80% of the maximum number of entries of the table. And probably you should also analyse, which application sets too many locks.

Regards,
Alwina

[Former Member]

Hi Alwina,

Thanks for your reply.

How to check which application sets too many locks ?

B.R

Michael

[former_member188883]

Hi Michael,

enque parameter value is not a bottleneck here as we have enough expansion opportunity .

Will it be possible for you to check the update trace files using SM50 for more details. Additionally please check work process as well as database logs for further inputs on the issue.

Regards,

Deepak Kori

[alwina_enns]

Hello Deepak,

I did not really understand about which expansion opportunity you are thinking in regard to the enqueue table overflow?

Thanks and regards, Alwina

[former_member188883]

Hi Alwina,

I see that the parameter "enque/table_size" has value 32768 . So with fill level 18218 I feel there should not be any enque overflow.

Also in case there are enque overflows we normally see an abap dump or sm21 logs which can be used for further investigation.

Regards,

Deepak Kori

[alwina_enns]

Hello Deepak,

but Michael wrote:

"Maximum number of Lock Entries is 18218 and Maximum Fill level is also 18218"

this is already an enqueue table overflow, and yes, in SM21 it should be logged and was most likely logged, Michael did not mention, that he has checked it.

Regards,
Alwina