Re: Deadlocks-a mystery

My appology if this is psoted twice, bit I wasn't sure if the first one went through.

We had problems with deadlocks which weren't directly related to the application. They were caused by badly configured INITRANS parameters. In our case we had a lot of transactions accessing two tables (Table A and Table B).
Once in a while it happend that a transaction updated A and wanted to update table B but had to wait for the lock because there was no space left in the database block to enter another transaction entry. Another transaction which had a lock on the database block of table B, which the first transactions tried to update, wanted to update Table A. If there was no space left in the database block of table A for another transaction entry the second transaction had to wait too, which caused the deadlock.

These kind of deadlock problems can be identfied by looking at the deadlock graph following the ORA-60 message. An indication for this kind of deadlocks is the Lock Type "TX" and the Mode Requested "S" and "Rows waited on:" has "no row".

If that's the cause for your deadlocks you have to increase the INITRANS parameter of the object.

Hope that helps.

Peter

In article <388e6032_4_at_news1.prserv.net>,   "Mr. Straits" <mr_straits_at_yahoo.com> wrote:
> All,
> We daily get over 5-6 deadlocks everyday and each of them are
different. Our
> DBA forwards the trace file to me everyday. The trace file says that
it is
> an application error and not an Oracle Error. After looking at the
trace
> file, I can see what applications are contesting, but why do both the
> applications error out? My understanding is that when we get a
deadlock,
> Oracle gives that 0054 error to only session and the other session
should
> work normally.
> As I wrote earlier, its not always the same two applications. The
> applications are way different and the tables getting locked are also
> different. We are using Oracle 7.3.4.
> Any help on this is appreciated.
> Straits.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Jan 26 2000 - 04:04:32 CST