This website is not affiliated with, sponsored by, or approved by SAP AG.

Enqueue lock times (history)

Basis (Basis Technology Modules: Basis Component/System Administration, GUIs)

Moderators: Snowy, thx4allthefish

Enqueue lock times (history)

Postby DrSidewalk » Tue Jan 21, 2014 10:10 am

We're looking at a 24/7 process going in as we will soon bring onboard Australia. We beleive that we have certain jobs that may perform table locks rather than record locks, or multiple record locks for long durations of time, with obvious consequences to either Australia's DIalog or overnight processing jobs.
Asking the business if they have any jobs that hold locks on tables for a considerable amount of time is useless, as the original designers have long since left the business and although the new functional consultants know the business processes they don't know techncially what their jobs are doing.

As a result what I need to do is get a list of Enqueue process that may be open for say, more than 5 minutes, before being closed. I looked at SM12 and Extra options, but none allow me to view this kind of info.

Does anyone know (short of lock trace, which is out of the question) how I might achieve this?.
DrSidewalk
 
Posts: 180
Joined: Thu May 03, 2012 9:35 am

Re: Enqueue lock times (history)

Postby Zavaros » Tue Jan 21, 2014 1:35 pm

Hello,

have you tried the enqt kernel program.

http://help.sap.com/saphelp_sm32/helpda ... ameset.htm

Regards,
Zav

PS: hm ... reverse engineering the faulty designed programs and redesign the business processes to reduce resource usage ... Epic Quest :!:
In my experience companies agree on it only if the extra hardware is too expensive ... or you manage to prove that it is not harware issue.
Zavaros
 
Posts: 756
Joined: Thu Oct 24, 2002 10:50 pm
Location: Hungary

Re: Enqueue lock times (history)

Postby DrSidewalk » Wed Jan 22, 2014 6:37 am

Zavaros,

Does monitoring via that cause severe impact to the overal performance. I thought it did.

My understanding that Enqueue logs are kept in buffered tables. I can see when the enqueue is started, but I can't match it with Dequeue's to identify how long the lock was held for, which is what I'm trying to do. Ideally list all Enqueues that perhaps were held for more than 5 minutes, for example.

When I track all the function moduels that return such info they all make 'C' calls so I can't actually drill into the code to see what tables are being used. II have been informed that I should be able to call the Enqueue_read FM and possible request to see enqueues and dequeues, somehow match them up to determine the lock time.

A real chore indeed.
From this we can identify what enqueue actions held tables in lock for long period of time, and from that info identify the program/job. When we go to a 24/7 service with different time zone processing we could encounter issues if tables/records are held for extensive periods of time. In other words out evening batch update may lock many records and cause grief to Australia's dialog users.
DrSidewalk
 
Posts: 180
Joined: Thu May 03, 2012 9:35 am

Re: Enqueue lock times (history)

Postby Zavaros » Thu Jan 23, 2014 6:37 am

Hello,

I think, enqueue tables exist only in memory. There is no reason to store them permanently: locks are managed by the ENQ server. No other process has direct access to these data (to preserve consistency).

To match the lock begins with ends ... you could try enqueue trace in ST05/ST12 ... but I have doubts if it helps. In a live system it will create huge amount of logs with minimal information.

another issue: you assume that the home-developed programs handle the critical transactions correctly. If enqueue/dequeue is not called in the ABAP program then you'll see nothing in SM12 ... but there will be lock waits on database level.

Regards,
Zav
Zavaros
 
Posts: 756
Joined: Thu Oct 24, 2002 10:50 pm
Location: Hungary


Return to Basis

Who is online

Users browsing this forum: No registered users and 5 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.