Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Tuning deadlocks

RE: Tuning deadlocks

From: <>
Date: Fri, 16 Sep 2005 12:27:10 -0400
Message-ID: <>

Deadlocks are an application issue pure and simple. What you may be seeing is a case of how long the database needs to rollback the terminated process before allowing the other to proceed. This is more of a data volume and transaction size than anything else. To reduce the "resolution" time and maybe even kill the root problem have the developer redefine their transaction size. We ran into that some time ago with a PeopleSoft job that did a ton of updates on several tables and committed all of it's work only at the end. It was a guaranteed deadlock on Friday nights every week. The solution was to commit after each purchase order had been processed so that the logical unit of work went from the entire job to a purchase order.

BTW: PeopleSoft never could duplicate the problem. Wonder why when their demo database only had one purchase order??

-----Original Message-----

[] On Behalf Of Allen, Brandon Sent: Friday, September 16, 2005 11:47 AM To:; Subject: RE: Tuning deadlocks

What do you mean by "cope with"? I believe Oracle's only way of coping with deadlocks is to immediately terminate the transaction that detects the deadlock condition and roll it back, allowing the other transaction to proceed. I don't know why this would be done any quicker in one database than another unless one was just on a CPU-bound server so it was running more slowly in general. Deadlocks are generally a problem with the application configuration - you could look at the trace file created when it occurs to find the objects and SQL statements involved, then fix the application to prevent them from recurring.

-----Original Message-----

[]On Behalf Of Peter Dixon Sent: Friday, September 16, 2005 2:44 AM To:
Subject: Tuning deadlocks

I have two live databases running the same application, one of the databases
has deadlocks which the database seems to cope with quicker than the same
application running on the other database. It version and I have

checked the init.ora including hidden parameters like LM_DD_INTERVAL are there any other parameters which might resolve this problem?


Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

-- Received on Fri Sep 16 2005 - 11:29:17 CDT

Original text of this message