Database locks

JDE_DH1

Member
Hi All,

We have been facing an issue with our system. The system would encounter intermittent database locks while processing UBE's and cause for the job to go in a loop causing delays and system wide issues. The locking is random and impacts different tables/processes.

I was wondering if anyone is facing a similar situation. I will appreciate all suggestions.


E910, TR 9.1.4.4, AIX, Oracle DB
 

Larry_Jones

Legendary Poster
We've only run into this with ECO Update (R30510). This UBE manages to get into a deadly embrace with itself sometimes.
We have no suggestion for a fix. We've tried several things but this (R40510 and related BSFNs) is one big black box of spaghetti code.
What's really lovely is that when it happens and we kill the process, then resubmit with exact same parameters it runs just fine. Go figure.

Thankfully it only happens once a month or so now (used to be more often).
 

Tom_Davidson

VIP Member
JDE_DH1,

Locking is normal in a database, it protects you from accidentally overwriting a change because of two simultaneous updates. To you have a little more info as to why you think the locks are 'not valid'?

Some changes I can think of is reducing the amount of data you update in a UBE, thus lessening the chance that a row/page will be in-use, changing your timeout for users to a shorter time so users that leave transactions partially completed get timed out when they leave the PC running, and trying alternate scheduling of the UBEs.

Just some ideas.

Tom
 

JDE_DH1

Member
Thanks for the suggestion and the experience. We get into the same situation as Larry mentioned. For eg: The Batch posting (single threaded) will cause a lock on Batch Header, terminating the job fixes the backlog of waiting jobs and the batch as such when tried again posts fine. We did not have this issue on E812 DB2 and the posting job ran multi threaded at that time. Same applies to other jobs as well, we have started restarting the system nightly and this has eliminated the locking situation. But thats not what we would like to do ideally.
 
Top