Re: Dead Locks Require Immediate Help

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Fri, 1 Oct 1999 18:05:13 +0100
Message-ID: <938798615.12758.0.nnrp-08.9e984b29_at_news.demon.co.uk>


When a deadlock occurs (error 00060) you usually get a trace file dumped which identifies the two sessions and gives some idea about where the collision is occurring. Start by looking for these.

Deadlocks are often down to table-ordering in complex transactions, where two transactions lock data in different orders, so you usually have to rewrite part of the transaction code - init.ora parameters do not help.

However, sometimes the deadlocks are not about rows being locked, but about ITL lists being full and transactions blocking because they want different rows in each other's blocks, but can't put a transaction entry into the ITL until the other transaction terminates.

This can usually be resolved by identifying the problem table and recreating it with a larger value of INITRANS

--

Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

janjua wrote in message <37F4C16C.907ADB37_at_cableinet.co.uk>...

>Hi
>
> We are facing some serious problems on our production box.
>
>Its a 7.3.2 On RS6000 box AIX Datbase.
>
> The application is written in ProC and ProCobol. Its has both On line
>and Batch jobs there are no Stored Procedures.
>
> The hit Ratio in buffer cache is 95.6 and in Shared Pool area is
>95.2.
>
> Theere are a big number of Deadlocks which are reported by the
>application(Written in ProC and ProCobol.).
>Due to these reported dead locks the transactions fail and they have to
>be resubmitted time and again. We have some problem with application
>itself also we are ammending it.
>
> Please can any body advise us what to do . Any of the Parameters in
>INIT or increasing the intrans and max trans would give us any
>respit. How to change the intrans and maxtrans and what effect they
>would have.
>
> Any help
>
> Tahking You all in advance.
>
> Aamer
>
>Email. amer_jaanjua_at_hotmail.com
>
Received on Fri Oct 01 1999 - 19:05:13 CEST

Original text of this message