Respuesta : DEADLOCKS

#6 Alejandro Mesa

22/06/2005 - 19:17 | Informe spam

Mauro,

De la info posteada, debemos chequear cuales son los objetos:

2005-06-22 10:07:17.87 spid4 Node:1
2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67) CleanCnt:1
2005-06-22 10:07:17.87 spid4 Node:2
2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae) CleanCnt:2

El lock es a nivel de llave (db_id:object_id:index_id)

asi que necesitamos hacer la siguiente consulta:

select * from master..sysdatabases
where dbid = 7

use [la_bd_7]
go

select
object_name(2089058478) as recurso_en_nodo_1,
object_name(1782297409) as recurso_en_nodo_2

select
object_name([id]),
[name]
from
sysindexes
where
([id] = 2089058478 and indid = 2)
or ([id] = 1782297409 and indid = 6)

con esto podemos ver los recursos que participan en el deadlock. Puedes
postear el resultado de las consultas?

AMB

"Mauro" wrote:

2005-06-22 10:07:17.87 spid4 Node:1
2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67) CleanCnt:1 Mode: X Flags: 0x0
2005-06-22 10:07:17.87 spid4 Grant List 3::
2005-06-22 10:07:17.87 spid4 Owner:0x5eb36540 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:201 ECID:0
2005-06-22 10:07:17.87 spid4 SPID: 201 ECID: 0 Statement Type: DELETE Line #: 1
2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin transaction delete from table1 where ID = 1293285 delete from Element where ID = 1293285 delete from NElement where ID = 1293285 commit transaction
2005-06-22 10:07:17.87 spid4 Requested By:
2005-06-22 10:07:17.87 spid4 ResType:LockOwner Stype:'OR' Mode: U SPID:219 ECID:0 Ec:(0x554DB5A8) Value:0x57d6b020 Cost:(0/6CF0)
2005-06-22 10:07:17.87 spid4
2005-06-22 10:07:17.87 spid4 Node:2
2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae) CleanCnt:2 Mode: X Flags: 0x0
2005-06-22 10:07:17.87 spid4 Wait List:
2005-06-22 10:07:17.87 spid4 Owner:0x573b7a00 Mode: U Flg:0x0 Ref:1 Life:00000000 SPID:161 ECID:0
2005-06-22 10:07:17.87 spid4 SPID: 161 ECID: 0 Statement Type: DELETE Line #: 1
2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin transaction delete from table1 where ID = 1293285 delete from Element where ID = 1293285 delete from NElement where ID = 1293285 commit transaction

"Alejandro Mesa" wrote in message news:
> Mauro,
>
> > sipi, son varios procesos tratando de aceder a la misma fila para borrarla,
> > por algun motivo da deadlock en lugar de timeout
>
> Eso no creo que sea la causa del deadlock. Aca te paso un link que explica
> como hacer un trace y como interpretar el resultado.
>
> Tracing Deadlocks
> http://www.sqlservercentral.com/col...dlocks.asp
>
>
> AMB
>
>
> "Mauro" wrote:
>
> > sipi, son varios procesos tratando de aceder a la misma fila para borrarla,
> > por algun motivo da deadlock en lugar de timeout
> >
> > "Alejandro Mesa" wrote in message
> > news:
> > > Mauro,
> > >
> > > No deberia, pero no quiero ser absolutista. Pudistes detectar los procesos
> > y
> > > recursos que participaron en el deadlock?
> > >
> > >
> > > AMB
> > >
> > > "Mauro" wrote:
> > >
> > > > pueden dos procesos similares, por ejemplo el store procedure ejecutado
> > por
> > > > dos pocesos distintos generar deadlock?
> > > > por que pasa esto si en teoria piden los recursos de la misma forma?
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >

Responder a este mensaje

#7 Mauro

22/06/2005 - 19:41 | Informe spam

la primera devuelve:

recurso_en_nodo_1 recurso_en_nodo_2
Conference Route

la segunda devuelve

no clumn name name
Route
IDX_Route_DestNumber_netelementid_Internal_Parent_CarrierID
Conference idx_confcalls

"Alejandro Mesa" wrote in message
news:

Mauro,

De la info posteada, debemos chequear cuales son los objetos:

> 2005-06-22 10:07:17.87 spid4 Node:1
> 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)

CleanCnt:1

> 2005-06-22 10:07:17.87 spid4 Node:2
> 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)

CleanCnt:2

El lock es a nivel de llave (db_id:object_id:index_id)

asi que necesitamos hacer la siguiente consulta:

select * from master..sysdatabases
where dbid = 7

use [la_bd_7]
go

select
object_name(2089058478) as recurso_en_nodo_1,
object_name(1782297409) as recurso_en_nodo_2

select
object_name([id]),
[name]
from
sysindexes
where
([id] = 2089058478 and indid = 2)
or ([id] = 1782297409 and indid = 6)

con esto podemos ver los recursos que participan en el deadlock. Puedes
postear el resultado de las consultas?

AMB

"Mauro" wrote:

> 2005-06-22 10:07:17.87 spid4 Node:1
> 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)

CleanCnt:1 Mode: X Flags: 0x0

> 2005-06-22 10:07:17.87 spid4 Grant List 3::
> 2005-06-22 10:07:17.87 spid4 Owner:0x5eb36540 Mode: X

Flg:0x0 Ref:0 Life:02000000 SPID:201 ECID:0

> 2005-06-22 10:07:17.87 spid4 SPID: 201 ECID: 0 Statement Type:

DELETE Line #: 1

> 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin

transaction delete from table1 where ID = 1293285 delete from Element where
ID = 1293285 delete from NElement where ID = 1293285 commit transaction

> 2005-06-22 10:07:17.87 spid4 Requested By:
> 2005-06-22 10:07:17.87 spid4 ResType:LockOwner Stype:'OR' Mode: U

SPID:219 ECID:0 Ec:(0x554DB5A8) Value:0x57d6b020 Cost:(0/6CF0)

> 2005-06-22 10:07:17.87 spid4
> 2005-06-22 10:07:17.87 spid4 Node:2
> 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)

CleanCnt:2 Mode: X Flags: 0x0

> 2005-06-22 10:07:17.87 spid4 Wait List:
> 2005-06-22 10:07:17.87 spid4 Owner:0x573b7a00 Mode: U

Flg:0x0 Ref:1 Life:00000000 SPID:161 ECID:0

> 2005-06-22 10:07:17.87 spid4 SPID: 161 ECID: 0 Statement Type:

DELETE Line #: 1

> 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin

transaction delete from table1 where ID = 1293285 delete from Element where
ID = 1293285 delete from NElement where ID = 1293285 commit transaction

>
>
> "Alejandro Mesa" wrote in

message news:

> > Mauro,
> >
> > > sipi, son varios procesos tratando de aceder a la misma fila para

borrarla,

> > > por algun motivo da deadlock en lugar de timeout
> >
> > Eso no creo que sea la causa del deadlock. Aca te paso un link que

explica

> > como hacer un trace y como interpretar el resultado.
> >
> > Tracing Deadlocks
> > http://www.sqlservercentral.com/col...dlocks.asp
> >
> >
> > AMB
> >
> >
> > "Mauro" wrote:
> >
> > > sipi, son varios procesos tratando de aceder a la misma fila para

borrarla,

> > > por algun motivo da deadlock en lugar de timeout
> > >
> > > "Alejandro Mesa" wrote in

message

> > > news:
> > > > Mauro,
> > > >
> > > > No deberia, pero no quiero ser absolutista. Pudistes detectar los

procesos

> > > y
> > > > recursos que participaron en el deadlock?
> > > >
> > > >
> > > > AMB
> > > >
> > > > "Mauro" wrote:
> > > >
> > > > > pueden dos procesos similares, por ejemplo el store procedure

ejecutado

> > > por
> > > > > dos pocesos distintos generar deadlock?
> > > > > por que pasa esto si en teoria piden los recursos de la misma

forma?

> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >

Responder a este mensaje

#8 Alejandro Mesa

22/06/2005 - 20:09 | Informe spam

Mauro,

Al menos que hayas cambiado los nombres de las tablas en las sentencias
delete por problemas de confidencialidad y proteccion, estas tablas
(Conference y Route) no estan presentes en las sentencias.

Nodo:1

begin transaction
delete from table1 where ID = 1293285
delete from Element where ID = 1293285
delete from NElement where ID = 1293285
commit transaction

Nodo:2

begin transaction
delete from table1 where ID = 1293285
delete from Element where ID = 1293285
delete from NElement where ID = 1293285
commit transaction

Sabes si existe algun trigger asociado a las tablas que aparecen en las
sentencias delete?

AMB

"Mauro" wrote:

la primera devuelve:

recurso_en_nodo_1 recurso_en_nodo_2
Conference Route

la segunda devuelve

no clumn name name
Route
IDX_Route_DestNumber_netelementid_Internal_Parent_CarrierID
Conference idx_confcalls

"Alejandro Mesa" wrote in message
news:
> Mauro,
>
> De la info posteada, debemos chequear cuales son los objetos:
>
> > 2005-06-22 10:07:17.87 spid4 Node:1
> > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
CleanCnt:1
> > 2005-06-22 10:07:17.87 spid4 Node:2
> > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
CleanCnt:2
>
> El lock es a nivel de llave (db_id:object_id:index_id)
>
> asi que necesitamos hacer la siguiente consulta:
>
> select * from master..sysdatabases
> where dbid = 7
>
> use [la_bd_7]
> go
>
> select
> object_name(2089058478) as recurso_en_nodo_1,
> object_name(1782297409) as recurso_en_nodo_2
>
> select
> object_name([id]),
> [name]
> from
> sysindexes
> where
> ([id] = 2089058478 and indid = 2)
> or ([id] = 1782297409 and indid = 6)
>
> con esto podemos ver los recursos que participan en el deadlock. Puedes
> postear el resultado de las consultas?
>
>
> AMB
>
> "Mauro" wrote:
>
> > 2005-06-22 10:07:17.87 spid4 Node:1
> > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
CleanCnt:1 Mode: X Flags: 0x0
> > 2005-06-22 10:07:17.87 spid4 Grant List 3::
> > 2005-06-22 10:07:17.87 spid4 Owner:0x5eb36540 Mode: X
Flg:0x0 Ref:0 Life:02000000 SPID:201 ECID:0
> > 2005-06-22 10:07:17.87 spid4 SPID: 201 ECID: 0 Statement Type:
DELETE Line #: 1
> > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
transaction delete from table1 where ID = 1293285 delete from Element where
ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> > 2005-06-22 10:07:17.87 spid4 Requested By:
> > 2005-06-22 10:07:17.87 spid4 ResType:LockOwner Stype:'OR' Mode: U
SPID:219 ECID:0 Ec:(0x554DB5A8) Value:0x57d6b020 Cost:(0/6CF0)
> > 2005-06-22 10:07:17.87 spid4
> > 2005-06-22 10:07:17.87 spid4 Node:2
> > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
CleanCnt:2 Mode: X Flags: 0x0
> > 2005-06-22 10:07:17.87 spid4 Wait List:
> > 2005-06-22 10:07:17.87 spid4 Owner:0x573b7a00 Mode: U
Flg:0x0 Ref:1 Life:00000000 SPID:161 ECID:0
> > 2005-06-22 10:07:17.87 spid4 SPID: 161 ECID: 0 Statement Type:
DELETE Line #: 1
> > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
transaction delete from table1 where ID = 1293285 delete from Element where
ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> >
> >
> > "Alejandro Mesa" wrote in
message news:
> > > Mauro,
> > >
> > > > sipi, son varios procesos tratando de aceder a la misma fila para
borrarla,
> > > > por algun motivo da deadlock en lugar de timeout
> > >
> > > Eso no creo que sea la causa del deadlock. Aca te paso un link que
explica
> > > como hacer un trace y como interpretar el resultado.
> > >
> > > Tracing Deadlocks
> > > http://www.sqlservercentral.com/col...dlocks.asp
> > >
> > >
> > > AMB
> > >
> > >
> > > "Mauro" wrote:
> > >
> > > > sipi, son varios procesos tratando de aceder a la misma fila para
borrarla,
> > > > por algun motivo da deadlock en lugar de timeout
> > > >
> > > > "Alejandro Mesa" wrote in
message
> > > > news:
> > > > > Mauro,
> > > > >
> > > > > No deberia, pero no quiero ser absolutista. Pudistes detectar los
procesos
> > > > y
> > > > > recursos que participaron en el deadlock?
> > > > >
> > > > >
> > > > > AMB
> > > > >
> > > > > "Mauro" wrote:
> > > > >
> > > > > > pueden dos procesos similares, por ejemplo el store procedure
ejecutado
> > > > por
> > > > > > dos pocesos distintos generar deadlock?
> > > > > > por que pasa esto si en teoria piden los recursos de la misma
forma?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >

Responder a este mensaje

#9 Mauro

22/06/2005 - 20:19 | Informe spam

asi es, la sentencia es:

begin transaction;
delete from route where netelementid = 1293285;
delete from h323element where netelementid = 1293285;
delete from Netelement where netelementid = 1293285;
commit

no hay trigers en ninguna de las tablas

"Alejandro Mesa" wrote in message
news:

Mauro,

Al menos que hayas cambiado los nombres de las tablas en las sentencias
delete por problemas de confidencialidad y proteccion, estas tablas
(Conference y Route) no estan presentes en las sentencias.

Nodo:1

begin transaction
delete from table1 where ID = 1293285
delete from Element where ID = 1293285
delete from NElement where ID = 1293285
commit transaction

Nodo:2

begin transaction
delete from table1 where ID = 1293285
delete from Element where ID = 1293285
delete from NElement where ID = 1293285
commit transaction

Sabes si existe algun trigger asociado a las tablas que aparecen en las
sentencias delete?

AMB

"Mauro" wrote:

> la primera devuelve:
>
> recurso_en_nodo_1 recurso_en_nodo_2
> Conference Route
>
> la segunda devuelve
>
> no clumn name name
> Route
> IDX_Route_DestNumber_netelementid_Internal_Parent_CarrierID
> Conference idx_confcalls
>
>
>
>
>
>
> "Alejandro Mesa" wrote in

message

> news:
> > Mauro,
> >
> > De la info posteada, debemos chequear cuales son los objetos:
> >
> > > 2005-06-22 10:07:17.87 spid4 Node:1
> > > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
> CleanCnt:1
> > > 2005-06-22 10:07:17.87 spid4 Node:2
> > > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
> CleanCnt:2
> >
> > El lock es a nivel de llave (db_id:object_id:index_id)
> >
> > asi que necesitamos hacer la siguiente consulta:
> >
> > select * from master..sysdatabases
> > where dbid = 7
> >
> > use [la_bd_7]
> > go
> >
> > select
> > object_name(2089058478) as recurso_en_nodo_1,
> > object_name(1782297409) as recurso_en_nodo_2
> >
> > select
> > object_name([id]),
> > [name]
> > from
> > sysindexes
> > where
> > ([id] = 2089058478 and indid = 2)
> > or ([id] = 1782297409 and indid = 6)
> >
> > con esto podemos ver los recursos que participan en el deadlock.

Puedes

> > postear el resultado de las consultas?
> >
> >
> > AMB
> >
> > "Mauro" wrote:
> >
> > > 2005-06-22 10:07:17.87 spid4 Node:1
> > > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
> CleanCnt:1 Mode: X Flags: 0x0
> > > 2005-06-22 10:07:17.87 spid4 Grant List 3::
> > > 2005-06-22 10:07:17.87 spid4 Owner:0x5eb36540 Mode: X
> Flg:0x0 Ref:0 Life:02000000 SPID:201 ECID:0
> > > 2005-06-22 10:07:17.87 spid4 SPID: 201 ECID: 0 Statement

Type:

> DELETE Line #: 1
> > > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
> transaction delete from table1 where ID = 1293285 delete from Element

where

> ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> > > 2005-06-22 10:07:17.87 spid4 Requested By:
> > > 2005-06-22 10:07:17.87 spid4 ResType:LockOwner Stype:'OR'

Mode: U

> SPID:219 ECID:0 Ec:(0x554DB5A8) Value:0x57d6b020 Cost:(0/6CF0)
> > > 2005-06-22 10:07:17.87 spid4
> > > 2005-06-22 10:07:17.87 spid4 Node:2
> > > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
> CleanCnt:2 Mode: X Flags: 0x0
> > > 2005-06-22 10:07:17.87 spid4 Wait List:
> > > 2005-06-22 10:07:17.87 spid4 Owner:0x573b7a00 Mode: U
> Flg:0x0 Ref:1 Life:00000000 SPID:161 ECID:0
> > > 2005-06-22 10:07:17.87 spid4 SPID: 161 ECID: 0 Statement

Type:

> DELETE Line #: 1
> > > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
> transaction delete from table1 where ID = 1293285 delete from Element

where

> ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> > >
> > >
> > > "Alejandro Mesa" wrote in
> message news:
> > > > Mauro,
> > > >
> > > > > sipi, son varios procesos tratando de aceder a la misma fila

para

> borrarla,
> > > > > por algun motivo da deadlock en lugar de timeout
> > > >
> > > > Eso no creo que sea la causa del deadlock. Aca te paso un link que
> explica
> > > > como hacer un trace y como interpretar el resultado.
> > > >
> > > > Tracing Deadlocks
> > > >

http://www.sqlservercentral.com/col...dlocks.asp

> > > >
> > > >
> > > > AMB
> > > >
> > > >
> > > > "Mauro" wrote:
> > > >
> > > > > sipi, son varios procesos tratando de aceder a la misma fila

para

> borrarla,
> > > > > por algun motivo da deadlock en lugar de timeout
> > > > >
> > > > > "Alejandro Mesa" wrote

in

> message
> > > > > news:
> > > > > > Mauro,
> > > > > >
> > > > > > No deberia, pero no quiero ser absolutista. Pudistes detectar

los

> procesos
> > > > > y
> > > > > > recursos que participaron en el deadlock?
> > > > > >
> > > > > >
> > > > > > AMB
> > > > > >
> > > > > > "Mauro" wrote:
> > > > > >
> > > > > > > pueden dos procesos similares, por ejemplo el store

procedure

> ejecutado
> > > > > por
> > > > > > > dos pocesos distintos generar deadlock?
> > > > > > > por que pasa esto si en teoria piden los recursos de la

misma

> forma?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
>
>
>

Responder a este mensaje

#10 Alejandro Mesa

22/06/2005 - 20:43 | Informe spam

Mauro,

La tabla [Conference] no la veo en las sentencias delete, tienes alguna idea
de por que aparece esta tabla involucrada en la transaccion?

AMB

"Mauro" wrote:

asi es, la sentencia es:

begin transaction;
delete from route where netelementid = 1293285;
delete from h323element where netelementid = 1293285;
delete from Netelement where netelementid = 1293285;
commit

no hay trigers en ninguna de las tablas

"Alejandro Mesa" wrote in message
news:
> Mauro,
>
> Al menos que hayas cambiado los nombres de las tablas en las sentencias
> delete por problemas de confidencialidad y proteccion, estas tablas
> (Conference y Route) no estan presentes en las sentencias.
>
> Nodo:1
>
> begin transaction
> delete from table1 where ID = 1293285
> delete from Element where ID = 1293285
> delete from NElement where ID = 1293285
> commit transaction
>
> Nodo:2
>
> begin transaction
> delete from table1 where ID = 1293285
> delete from Element where ID = 1293285
> delete from NElement where ID = 1293285
> commit transaction
>
> Sabes si existe algun trigger asociado a las tablas que aparecen en las
> sentencias delete?
>
>
> AMB
>
> "Mauro" wrote:
>
> > la primera devuelve:
> >
> > recurso_en_nodo_1 recurso_en_nodo_2
> > Conference Route
> >
> > la segunda devuelve
> >
> > no clumn name name
> > Route
> > IDX_Route_DestNumber_netelementid_Internal_Parent_CarrierID
> > Conference idx_confcalls
> >
> >
> >
> >
> >
> >
> > "Alejandro Mesa" wrote in
message
> > news:
> > > Mauro,
> > >
> > > De la info posteada, debemos chequear cuales son los objetos:
> > >
> > > > 2005-06-22 10:07:17.87 spid4 Node:1
> > > > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
> > CleanCnt:1
> > > > 2005-06-22 10:07:17.87 spid4 Node:2
> > > > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
> > CleanCnt:2
> > >
> > > El lock es a nivel de llave (db_id:object_id:index_id)
> > >
> > > asi que necesitamos hacer la siguiente consulta:
> > >
> > > select * from master..sysdatabases
> > > where dbid = 7
> > >
> > > use [la_bd_7]
> > > go
> > >
> > > select
> > > object_name(2089058478) as recurso_en_nodo_1,
> > > object_name(1782297409) as recurso_en_nodo_2
> > >
> > > select
> > > object_name([id]),
> > > [name]
> > > from
> > > sysindexes
> > > where
> > > ([id] = 2089058478 and indid = 2)
> > > or ([id] = 1782297409 and indid = 6)
> > >
> > > con esto podemos ver los recursos que participan en el deadlock.
Puedes
> > > postear el resultado de las consultas?
> > >
> > >
> > > AMB
> > >
> > > "Mauro" wrote:
> > >
> > > > 2005-06-22 10:07:17.87 spid4 Node:1
> > > > 2005-06-22 10:07:17.87 spid4 KEY: 7:2089058478:2 (cf01a8654b67)
> > CleanCnt:1 Mode: X Flags: 0x0
> > > > 2005-06-22 10:07:17.87 spid4 Grant List 3::
> > > > 2005-06-22 10:07:17.87 spid4 Owner:0x5eb36540 Mode: X
> > Flg:0x0 Ref:0 Life:02000000 SPID:201 ECID:0
> > > > 2005-06-22 10:07:17.87 spid4 SPID: 201 ECID: 0 Statement
Type:
> > DELETE Line #: 1
> > > > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
> > transaction delete from table1 where ID = 1293285 delete from Element
where
> > ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> > > > 2005-06-22 10:07:17.87 spid4 Requested By:
> > > > 2005-06-22 10:07:17.87 spid4 ResType:LockOwner Stype:'OR'
Mode: U
> > SPID:219 ECID:0 Ec:(0x554DB5A8) Value:0x57d6b020 Cost:(0/6CF0)
> > > > 2005-06-22 10:07:17.87 spid4
> > > > 2005-06-22 10:07:17.87 spid4 Node:2
> > > > 2005-06-22 10:07:17.87 spid4 KEY: 7:1782297409:6 (4002f9b897ae)
> > CleanCnt:2 Mode: X Flags: 0x0
> > > > 2005-06-22 10:07:17.87 spid4 Wait List:
> > > > 2005-06-22 10:07:17.87 spid4 Owner:0x573b7a00 Mode: U
> > Flg:0x0 Ref:1 Life:00000000 SPID:161 ECID:0
> > > > 2005-06-22 10:07:17.87 spid4 SPID: 161 ECID: 0 Statement
Type:
> > DELETE Line #: 1
> > > > 2005-06-22 10:07:17.87 spid4 Input Buf: Language Event: begin
> > transaction delete from table1 where ID = 1293285 delete from Element
where
> > ID = 1293285 delete from NElement where ID = 1293285 commit transaction
> > > >
> > > >
> > > > "Alejandro Mesa" wrote in
> > message news:
> > > > > Mauro,
> > > > >
> > > > > > sipi, son varios procesos tratando de aceder a la misma fila
para
> > borrarla,
> > > > > > por algun motivo da deadlock en lugar de timeout
> > > > >
> > > > > Eso no creo que sea la causa del deadlock. Aca te paso un link que
> > explica
> > > > > como hacer un trace y como interpretar el resultado.
> > > > >
> > > > > Tracing Deadlocks
> > > > >
http://www.sqlservercentral.com/col...dlocks.asp
> > > > >
> > > > >
> > > > > AMB
> > > > >
> > > > >
> > > > > "Mauro" wrote:
> > > > >
> > > > > > sipi, son varios procesos tratando de aceder a la misma fila
para
> > borrarla,
> > > > > > por algun motivo da deadlock en lugar de timeout
> > > > > >
> > > > > > "Alejandro Mesa" wrote
in
> > message
> > > > > > news:
> > > > > > > Mauro,
> > > > > > >
> > > > > > > No deberia, pero no quiero ser absolutista. Pudistes detectar
los
> > procesos
> > > > > > y
> > > > > > > recursos que participaron en el deadlock?
> > > > > > >
> > > > > > >
> > > > > > > AMB
> > > > > > >
> > > > > > > "Mauro" wrote:
> > > > > > >
> > > > > > > > pueden dos procesos similares, por ejemplo el store
procedure
> > ejecutado
> > > > > > por
> > > > > > > > dos pocesos distintos generar deadlock?
> > > > > > > > por que pasa esto si en teoria piden los recursos de la
misma
> > forma?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> >
> >
> >

Responder a este mensaje

Ads by Google

DEADLOCKS

Preguntas similare

Leer las respuestas