DEADLOCKS

mm ni idea voy a buscar un deadlock mas pequeño
"Alejandro Mesa" wrote in message
news:

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?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > >
> > >
> > >
>
>
>

de todos modos, si es la misma consulta, por que busca usar los indices en
distinto orden?

"Alejandro Mesa" wrote in message
news:

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?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > >
> > >
> > >
>
>
>

Mauro,

Creeme que quisiera ayudarte, pero sin mas informacion acerca de la bd asi
como de los procesos involucrados no tengo la menor idea de lo que pueda
estar pasando.


AMB

"Mauro" wrote:

de todos modos, si es la misma consulta, por que busca usar los indices en
distinto orden?

"Alejandro Mesa" wrote in message
news:
> 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?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > >
> > > >
> > > >
> >
> >
> >

ok, voy a juntar mas info, y te la voy a pasar

"Alejandro Mesa" wrote in message
news:

Mauro,

Creeme que quisiera ayudarte, pero sin mas informacion acerca de la bd asi
como de los procesos involucrados no tengo la menor idea de lo que pueda
estar pasando.


AMB

"Mauro" wrote:

> de todos modos, si es la misma consulta, por que busca usar los indices

en

> distinto orden?
>
> "Alejandro Mesa" wrote in

message

> news:
> > 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?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>