Interbloqueo en INSERT
Victor Koch arroba punto punto punto
Tengo una aplicaci�n ERP desarrollada en VB6. Esta aplicaci�n esta corriendo
hace varios a�os en cientos de clientes, dem�s esta decir que la aplicaci�n
es multiusuario y los clientes la usan en varias terminales a la vez, hasta
ahora nunca tuve reportes de mis clientes de errores de interbloqueo.
Un cliente se hizo desarrollar una aplicaci�n, tambi�n en VB6, que accede a
la base de datos, SS2000, de mi sistema, esta aplicaci�n lee y graba en la
base de datos.
El problema que estoy teniendo, con bastante frecuencia, en mi sistema es
que salta el error 1205, es decir mi transacci�n fue elegida como sujeto del
interbloqueo, pero lo raro es que siempre salta en los INSERT.
Mi aplicaci�n cada vez que detecta un error al leer o grabar en la base
graba en un archivo secuencial un log de errores y cancela la transacci�n,
les pego uno de los errores de interbloqueo.
7.0.451 06/08/2009 13:28:43 Usuario: MA�ANA PC Name: VMCAJA Usuario de
red: VMCaja
Operacion: Insertando Items Error Nro.:-2147467259 Descripcion: La
transacci�n (id. de proceso 57) qued� en interbloqueo en bloqueo recursos
con otro proceso y fue elegida como sujeto del interbloqueo. Ejecute de
nuevo la transacci�n.
Origen: Microsoft OLE DB Provider for SQL Server Estado de SQL:
40001 Error nativo: 1205
Sentencia: INSERT INTO ITITEMS
(FECEMISION,CODMOV,NROCOMP,LETRA,ITEM,ARTICULO,REGISTRO,ES,SIGNO,PRESENTA,DESCUENTO,LISTAPRE,COMISION,BULTOS,UNIDADES,PIEZAS,OPERACION,DESPACHO,TASA,PRECIOML,PRECIOIMML,TOTALML,GRAVT1ML,NOGRAVT1ML,IVAT1ML,IVANOIT1ML,BONIFICML,PPPML,PUCML,COMISIONML,PERCIBML,PERCIVAML,IMPINTML,DESCARTML,PRECVTAML,RECFINML,FILLER1,PRECIOME,PRECIOIMME,TOTALME,GRAVT1ME,NOGRAVT1ME,IVAT1ME,IVANOIT1ME,BONIFICME,PPPME,PUCME,COMISIONME,PERCIBME,PERCIVAME,IMPINTME,DESCARTME,PRECVTAME,RECFINME,ITEMPED,PARTIDA,FECTRANS,DESCART,FECANULACION,DEPARTAMENTO,NROREQ,ITEMREQ,PLANILLA,FILLER,FECALTA,USUARIO,FACTURA)
VALUES ({d
'2009-08-06'},'65','030300348552','A','0001','1200000007','70','S',-1,'03',
0,'01', 0, 1, 1, 0,NULL,NULL,'1', 3950, 4345, 4345, 3950, 0, 395, 0, 0,
3000.713, 1155.25, 0, 0, 0, 0, 0, 3950, 0,NULL, .94, 1.03, 1.03, .94, 0,
.09, 0, 0, .72, .25, 0, 0, 0, 0, 0, .94,
0,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,{ts '2009-08-06
13:28:32'},'MA�ANA',NULL)
Todavia no hable con el programador para saber como esta accediendo y
actualizando la base de datos, porque es de otro pa�s, pero yo sospecho que
esa aplicaci�n externa esta haciendo mal uso o abuso de la base de datos,
creo que la forma de acceder y actualizar la base no es la correcta, me
inclino a que el programador usa DataControl o abre recordsets para insertar
o actualizar registros bloqueando por demas�a paginas de registros.
La pregunta es:
Puede ser que haciendo abuso o mal uso de recordset's para insertar y
actualizar registros se castiguen los INSERT y salte el error de
interbloqueo ?
Gracias.
--
Un Saludo, V�ctor Koch
Ruben Garrigos
Es muy probable que el problema s� venga por lo que comentas, por el abuso
de otra aplicaci�n. El problema es que en estas situaciones el que sale "perdiendo"
es el que lo hace peor. Es decir, SQL Server trata a todas las operaciones
como si fuesen igualmente correctas y razonables ante un interbloqueo. La
v�ctima se elegir� en funci�n del coste que tenga hacer el rollback de cada
operaci�n, haciendose rollback de aquellas menos costosas de deshacer (potencialmente
las mejores implementadas).
Ante una situaci�n como esta lo que podr�as hacer es monitorizar los bloqueos,
la duraci�n de �stos, etc. de forma que puedas demostrar a la otra parte
que lo que est� haciendo es muy discutible desde el punto de vista t�cnico,
de rendimiento, etc.
Suerte! :)
Un saludo,
Rub�n Garrig�s
Solid Quality Mentors
Blog: http://blogs.solidq.com/es/elrincondeldba
Victor Koch arroba punto punto punto
Gracias por contestar tan r�pido.
Por tu respuesta veo que mi razonamiento fue correcto.
No quise excederme en el mail pero en principio supuse que se castiga mi
aplicaci�n porque el mal uso o abuso de los recordset desparrama bloqueos
por cientos de registros y paginas y seguro que el coste de deshacer esa
transacci�n va a ser muy alto con respecto a mi m�todo, as� que salgo
perdiendo yo.
Voy a ver si de alguna manera se puede monitorear los bloqueos, eso es solo
una parte, porque en ese caso hay tres actores, el programador externo, el
cliente y yo, y lo peor que el cliente mide los resultados y seg�n palabras
de el "los interbloqueos saltan en mi aplicaci�n, en la otra tarda mucho en
grabar pero no salta el error".
--
Un Saludo, V�ctor Koch
"Ruben Garrigos" <rgarrigo...@solidq.com> escribi� en el mensaje
news:2ec7293313e88...@news.microsoft.com...
Ruben Garrigos
Puedes examinar los bloqueos con el procedimiento sp_lock (o alguna de sus
versiones mejoradas como sp_lock2) Si el desarrollador/cliente "juegan sucio"
tu tambi�n puedes "ayudarte" fijando la prioridad para ser v�ctima de deadlock.
Ejecutando "SET DEADLOCK_PRIORITY HIGH" en tu sesi�n conseguiras no ser elegido
v�ctima ante dichas situaciones (salvo que el desarrollador tambi�n est�
haciendo lo mismo). A igualdad de prioridad se tiene en cuenta el coste del
rollback, pero la prioridad va primero por lo que tu proceso saldr� "vencedor".
Un saludo,
Rub�n Garrig�s
Solid Quality Mentors
Blog: http://blogs.solidq.com/es/elrincondeldba
> Hola Rub�n,
>
> Gracias por contestar tan r�pido.
>
> Por tu respuesta veo que mi razonamiento fue correcto.
>
> No quise excederme en el mail pero en principio supuse que se castiga
> mi aplicaci�n porque el mal uso o abuso de los recordset desparrama
> bloqueos por cientos de registros y paginas y seguro que el coste de
> deshacer esa transacci�n va a ser muy alto con respecto a mi m�todo,
> as� que salgo perdiendo yo.
>
> Voy a ver si de alguna manera se puede monitorear los bloqueos, eso es
> solo una parte, porque en ese caso hay tres actores, el programador
> externo, el cliente y yo, y lo peor que el cliente mide los resultados
> y seg�n palabras de el "los interbloqueos saltan en mi aplicaci�n, en
> la otra tarda mucho en grabar pero no salta el error".
>
Victor Koch arroba punto punto punto
Voy a ver si puedo ir por las buenas, sino har� uso del "SET
DEADLOCK_PRIORITY HIGH".
--
Un Saludo, V�ctor Koch
"Ruben Garrigos" <rgarrigo...@solidq.com> escribi� en el mensaje
news:2ec7293313fd8...@news.microsoft.com...
Alejandro Mesa
No podemos decidir aun si esa aplicacion es la que esta causando el
problema, sin antes identificar las partes que participan en el deadlock. Te
recomiendo que trates de capturar el grafo de deadlock desde profiler o usar
las respectivas flags que hacen volvar la informacion en el log de errores de
sql server.
The Anatomy of a Deadlock
http://sqlblog.com/blogs/jonathan_kehayias/archive/2008/07/30/the-anatomy-of-a-deadlock.aspx
Deadlock Troubleshooting, Part 1
http://blogs.msdn.com/bartd/archive/2006/09/09/Deadlock-Troubleshooting_2C00_-Part-1.aspx
Deadlock Troubleshooting, Part 2
http://blogs.msdn.com/bartd/archive/2006/09/13/Deadlock-Troubleshooting_2C00_-Part-2.aspx
Deadlock Troubleshooting, Part 3
http://blogs.msdn.com/bartd/archive/2006/09/25/deadlock-troubleshooting-part-3.aspx
AMB
"Victor Koch" wrote:
> Ok, gracias.
>
> Voy a ver si puedo ir por las buenas, sino haré uso del "SET
> DEADLOCK_PRIORITY HIGH".
>
> --
> Un Saludo, Víctor Koch
>
>
>
> "Ruben Garrigos" <rgarrigo...@solidq.com> escribió en el mensaje
> news:2ec7293313fd8...@news.microsoft.com...
> > Hola Victor:
> >
> > Puedes examinar los bloqueos con el procedimiento sp_lock (o alguna de sus
> > versiones mejoradas como sp_lock2) Si el desarrollador/cliente "juegan
> > sucio" tu también puedes "ayudarte" fijando la prioridad para ser víctima
> > de deadlock. Ejecutando "SET DEADLOCK_PRIORITY HIGH" en tu sesión
> > conseguiras no ser elegido víctima ante dichas situaciones (salvo que el
> > desarrollador también esté haciendo lo mismo). A igualdad de prioridad se
> > tiene en cuenta el coste del rollback, pero la prioridad va primero por lo
> > que tu proceso saldrá "vencedor".
> >
> > Un saludo,
> >
> > Rubén Garrigós
> > Solid Quality Mentors
> >
> > Blog: http://blogs.solidq.com/es/elrincondeldba
> >
> >> Hola Rubén,
> >>
> >> Gracias por contestar tan rápido.
> >>
> >> Por tu respuesta veo que mi razonamiento fue correcto.
> >>
> >> No quise excederme en el mail pero en principio supuse que se castiga
> >> mi aplicación porque el mal uso o abuso de los recordset desparrama
> >> bloqueos por cientos de registros y paginas y seguro que el coste de
> >> deshacer esa transacción va a ser muy alto con respecto a mi método,
> >> así que salgo perdiendo yo.
> >>
> >> Voy a ver si de alguna manera se puede monitorear los bloqueos, eso es
> >> solo una parte, porque en ese caso hay tres actores, el programador
> >> externo, el cliente y yo, y lo peor que el cliente mide los resultados
> >> y según palabras de el "los interbloqueos saltan en mi aplicación, en
> >> la otra tarda mucho en grabar pero no salta el error".
> >>
> >> "Ruben Garrigos" <rgarrigo...@solidq.com> escribió en el mensaje
> >> news:2ec7293313e88...@news.microsoft.com...
> >>
> >>> Hola Victor:
> >>>
> >>> Es muy probable que el problema sí venga por lo que comentas, por el
> >>> abuso de otra aplicación. El problema es que en estas situaciones el
> >>> que sale "perdiendo" es el que lo hace peor. Es decir, SQL Server
> >>> trata a todas las operaciones como si fuesen igualmente correctas y
> >>> razonables ante un interbloqueo. La víctima se elegirá en función del
> >>> coste que tenga hacer el rollback de cada operación, haciendose
> >>> rollback de aquellas menos costosas de deshacer (potencialmente las
> >>> mejores implementadas).
> >>>
> >>> Ante una situación como esta lo que podrías hacer es monitorizar los
> >>> bloqueos, la duración de éstos, etc. de forma que puedas demostrar a
> >>> la
> >>> otra parte que lo que está haciendo es muy discutible desde el punto
> >>> de
> >>> vista técnico, de rendimiento, etc.
> >>> Suerte! :)
> >>> Un saludo,
> >>>
> >>> Rubén Garrigós
> >>> Solid Quality Mentors
> >>> Blog: http://blogs.solidq.com/es/elrincondeldba
> >>>
> >>>> Hola,
> >>>>
> >>>> Tengo una aplicación ERP desarrollada en VB6. Esta aplicación esta
> >>>> corriendo hace varios años en cientos de clientes, demás esta decir
> >>>> que la aplicación es multiusuario y los clientes la usan en varias
> >>>> terminales a la vez, hasta ahora nunca tuve reportes de mis clientes
> >>>> de errores de interbloqueo.
> >>>>
> >>>> Un cliente se hizo desarrollar una aplicación, también en VB6, que
> >>>> accede a la base de datos, SS2000, de mi sistema, esta aplicación
> >>>> lee y graba en la base de datos.
> >>>>
> >>>> El problema que estoy teniendo, con bastante frecuencia, en mi
> >>>> sistema es que salta el error 1205, es decir mi transacción fue
> >>>> elegida como sujeto del interbloqueo, pero lo raro es que siempre
> >>>> salta en los INSERT.
> >>>>
> >>>> Mi aplicación cada vez que detecta un error al leer o grabar en la
> >>>> base graba en un archivo secuencial un log de errores y cancela la
> >>>> transacción, les pego uno de los errores de interbloqueo.
> >>>>
> >>>> 7.0.451 06/08/2009 13:28:43 Usuario: MAÑANA PC Name: VMCAJA
> >>>> Usuario
> >>>> de
> >>>> red: VMCaja
> >>>> Operacion: Insertando Items Error Nro.:-2147467259
> >>>> Descripcion: La
> >>>> transacción (id. de proceso 57) quedó en interbloqueo en bloqueo
> >>>> recursos
> >>>> con otro proceso y fue elegida como sujeto del interbloqueo. Ejecute
> >>>> de
> >>>> nuevo la transacción.
> >>>> 13:28:32'},'MAÑANA',NULL)
> >>>> Todavia no hable con el programador para saber como esta accediendo
> >>>> y actualizando la base de datos, porque es de otro país, pero yo
> >>>> sospecho que esa aplicación externa esta haciendo mal uso o abuso de
> >>>> la base de datos, creo que la forma de acceder y actualizar la base
> >>>> no es la correcta, me inclino a que el programador usa DataControl o
> >>>> abre recordsets para insertar o actualizar registros bloqueando por
> >>>> demasía paginas de registros.