Resolver problema con bloqueo de tablas

Es complicado responderte... yo lo que haría sería generar una traza en
el Profiler para capturar las sentencias que se envían al servidor (eventos
RPC:Completed y SQL:BatchCompleted) y los bloqueos que se producen
(típicamente Lock:Acquired y/o Lock:Deadlock)

En cuanto al SELECT, es probable que el índice sea lo bastante
restrictivo como para que SQL no tenga que bloquear exclusivamente toda la
tabla, así que no creo que por ahí vayan los tiros... En cualquier caso, lo
que nos va a sacar de dudas va a ser el Profiler

"Manuel" escribió en el mensajenews:
Gracias por tus comentarios Carlos
Tenía incorporado el control de transacciones, pero por pruebas lo
quitamos... necesitabamos ver en que punto del proceso se estaba
provocando el problema, pues no nos esta ingresando nada asi que
al estar fuera del bloque transaccional, incorporamos un proceso
auditor tras el fin del proceso, para trabajar sobre los datos que
estan a medias...
luego que hayamos resuelto el problema, volveremos a incorporar el
bloque transaccional...

pero aun así, se sigue presentando el problema de los bloqueos lo cual
me deja sin poder cargar los datos, de que forma sería posible
salvarse esto?
según la consulta que me genera la aplicación principal, que es la
última tabla que se carga por medio de la aplicación en asp y
trabajando sin el bloque transaccional no registra datos en ninguna de
las otras tablas relacionadas, solo hace la actualización del control
de los correlativos.

en la instruccion
SELECT SucCod, ComAnoMes, ComTip, ComNum, ComDia, ComNumRef, ComEje,
ComEst, ComFchIng, ComMarUpd, EmpLla, ComFchMov, ComFchPrc, ComGru,
ComMon, ComGlo, ComUltLin, ComIteCod, ComEgrOtr, ComTotLin FROM
COMPROBA (UPDLOCK) WHERE SucCod = @P1 AND ComAnoMes = @P2 AND ComTip
> @P3 AND ComNum = @P4

estos son los campos clave
SucCod , ComAnoMes, ComTip, ComNum

Vaya, pues muchas gracias. No me imaginaba que se me pudiera echar de
menos.

La verdad es que he estado liado últimamente, tanto en el aspecto
personal como el laboral (ahora soy compañero de trabajo de Eladio Rincón,
Miguel Egea, Gustavo Larriera... o Fernando Guerrero, Itzik Ben-Gan... y
tantos otros de igual nivel que me dejo en el tintero por falta de espacio)


"Alejandro Mesa" escribió en el
mensaje news:
> Hola Carlos,
>
> Que bueno tenerte de vuelta.
>
> Saludos,
>
> Alejandro Mesa
>
> "Carlos Sacristan" wrote:
>
>> Comprueba el tipo de bloqueo que realiza la sentencia SELECT que
>> posteas
>> al final. Si SQL no tiene un índice útil que le sirva para reducir el
>> nivel
>> de bloqueo a fila, se ve obligado a realizarlo sobre la tabla, con lo que
>> el
>> resto de las conexiones se verán penalizadas.
>>
>> De todos modos, me choca que digas que a veces hace parte del
>> proceso...
>> eso supone que no hay transacciones, con los problemas de incoherencia de
>> datos que te puedes encontrar. Yo lo veo más importante al hecho de que
>> en
>> ciertos momentos se produzcan retrasos por bloqueos.
>>
>>
>> "Manuel" escribió en el mensaje
>> news:
>> Hola Foreros,
>> les saludo a todos desde Chile y los felicito por mantener viva la
>> comunidad...
>>
>> les cuento mi problema, estamos con un colega creando una aplicación
>> en asp para cargar datos sobre un par de tablas, que pertenecen a una
>> aplicación mayor, en la cual constantemente estan ingresando
>> información (no contamos con los fuentes de esta aplicación, ya que es
>> un paquete cerrado)
>>
>> Tablas
>> Comproba (cabecera comprobante)
>> Comprob1 (detalle comprobante)
>>
>> El proceso cuando lo hemos probado funciona bien, no se presenta
>> ningún problema al insertar, actualizar o eliminar registros, todo
>> esto probado con usuarios conectados a la aplicación principal y
>> trabajando desde la nuestra.
>> Pero resulta que cada cierto tiempo y de forma completamente aleatoria
>> no inserta los datos, esto nos tiene parados en este momento y sin
>> poder entregar la aplicación.
>> hay veces en que solo hace parte del proceso, otras en que no hace
>> absolutamente nada.
>>
>> Les envío el código de insersión para ambas tablas
>>
>> strInsertaCompro=""
>> strInsertaCompro=strInsertaCompro & "INSERT INTO
>> COMPROBA(SucCod,ComAnoMes,ComTip,ComNum,ComNumRef,ComFchMov,ComFchIng,ComEst,ComGlo,ComMarUpd,ComUltLin,ComTotLin"
>> strInsertaCompro=strInsertaCompro & " ,EmpLla,
>> ComDocNum,ComTipDoc,ComEje, ComGru, ComMon,
>> ComEgrMod,ComEgrFor,ComEgrCue "
>> strInsertaCompro=strInsertaCompro &
>> " ,ComEgrTip,ComEgrCod,ComEgrSec,ComEgrGir,ComEgrVal,ComEgrChe,ComEgrFch
>> "
>> strInsertaCompro=strInsertaCompro &
>> "
>> ,ComEgrEmi,ComAreCod,ComCenCod,ComFluTip,ComFluCod,ComOriCen,ComDia,ComMarRev,ComEgrOtr,ComIteCod
>> )"
>> strInsertaCompro=strInsertaCompro & " VALUES (0," & ANOMES & ",3," &
>> iserial & " ," & algo & ",'" & fechaMvto & "' ,'" & fechaMvto & "',
>> 2,'" & aaa & "', 0,2,2 "
>> strInsertaCompro=strInsertaCompro & " , 'EMP',0,0,0,0,0,0,0,0 "
>> strInsertaCompro=strInsertaCompro & " ,0,0,0,0,0,0,convert(datetime,'"
>> & Fec_Cent & "',103) "
>> strInsertaCompro=strInsertaCompro & " ,0,0,0,0,0,'CenCCb' ," & dia & ",
>> 0,0,0) "
>>
>> oConn.Execute (strInsertaCompro)
>>
>> strInserta=""
>> strInserta=strInserta & "INSERT INTO
>> COMPROB1(SucCod,ComAnoMes,ComTip,ComNum,ComLin,PlaCod,AreCod,CenCod,IteCod,AnaTip"
>> strInserta=strInserta & " , AnaSec, AnaCod, ComMmon,
>> ComDebNac,ComHabNac,ComDebOtr,ComHabOtr, ComGloDet, ComRefNum,
>> ComRefFch,"
>> strInserta=strInserta & " ComRefVto,ComTasCam,ComCorAud, FluTip,
>> FluCod, ComMarLib, ComFchMov, ComTipCar,ComCarNum,ComCarSec"
>> strInserta=strInserta &
>> " ,ComTipCal,ComFchCal,ComHabO,ComDebO,ComHabN,ComDebN )"
>> strInserta=strInserta & " VALUES (0, " & ANOMES & " ,3 ," & iserial &
>> "," & i & ",'" & var_paso_pla_cod & "'," & arecod & ", " & Cencod & ",
>> 0, " & anatip & " "
>> strInserta=strInserta & " ,0," & anacod & ",0," & d & "," & h &
>> ",cast(REPLACE(' " & dolard & "',',','.') as
>> decimal(18,2)),cast(REPLACE(' " & dolarh & "',',','.') as
>> decimal(18,2)),'" & ComGloDet & "', '" & NUM_GUIA_PROV & "' ,'" &
>> fechaMvto & "' "
>> strInserta=strInserta & " ,convert(datetime,'" & fechaMvto & "',
>> 103),cast(REPLACE(' " & comtaskam & "',',','.') as decimal(18,2))," &
>> i & ",0,0,1,convert(datetime,'" & fechaMvto & "',103),0,0,0 "
>> strInserta=strInserta & " ,0,convert(datetime,'" & Fec_Cent & "',
>> 103),cast(REPLACE(' " & dolarh & "',',','.') as decimal(18,2)) ,
>> cast(REPLACE(' " & dolard & "',',','.') as decimal(18,2))," & h & ","
>> & d & " ) "
>>
>> oConn.Execute (strInserta)
>>
>>
>> Cuando hemos trazado la aplicación principal con el analizador de sql
>> server, hemos conseguido el siguiente código.
>> Este código se presenta al momento de ir a ingresar el detalle del
>> comprobante.
>>
>> SELECT SucCod, ComAnoMes, ComTip, ComNum, ComDia, ComNumRef, ComEje,
>> ComEst, ComFchIng, ComMarUpd, EmpLla, ComFchMov, ComFchPrc, ComGru,
>> ComMon, ComGlo, ComUltLin, ComIteCod, ComEgrOtr, ComTotLin FROM
>> COMPROBA (UPDLOCK) WHERE SucCod = @P1 AND ComAnoMes = @P2 AND ComTip > >> @P3 AND ComNum = @P4
>>
>>
>> agradecería bastante cualquier tipo de ayuda que nos pudieran brindar,
>> o cualquier pista para poder resolver esto desde nuestra aplicación.
>>
>>
>> saludos
>>
>> Manuel Sandoval
>>
>>
>>

Carlos,

la instrucción que esta al final de la consulta la obtuve con el
profiler.
de todas maneras te adjunto la traza obtenida al momento de pasar
desde la cabecera del comprobante al detalle, que es cuando se
producen los problemas...

gracias



SELECT N'Testing Connection...'

EXECUTE msdb.dbo.sp_sqlagent_get_perf_counters

declare @P1 int
set @P14
exec sp_prepexec @P1 output, N'@P1 numeric(2,0),@P2 numeric(6,0),@P3
numeric(1,0),@P4 numeric(7,0),@P5 numeric(2,0),@P6 numeric(7,0),@P7
numeric(2,0),@P8 numeric(1,0),@P9 datetime,@P10 numeric(1,0),@P11
char(3),@P12 datetime,@P13 datetime,@P14 numeric(1,0),@P15
numeric(2,0),@P16 char(60),@P17 numeric(5,0),@P18 numeric(4,0),@P19
numeric(14,2),@P20 numeric(5,0)', N'INSERT INTO COMPROBA (SucCod,
ComAnoMes, ComTip, ComNum, ComDia, ComNumRef, ComEje, ComEst,
ComFchIng, ComMarUpd, EmpLla, ComFchMov, ComFchPrc, ComGru, ComMon,
ComGlo, ComUltLin, ComIteCod, ComEgrOtr, ComTotLin, ComDocNum,
ComTipDoc, ComOriCen, ComMarRev, ComEgrMod, ComEgrTip, ComEgrFor,
ComEgrCue, BcoCueCte, ComEgrCod, ComEgrSec, ComEgrGir, ComEgrVal,
ComEgrChe, ComEgrFch, ComEgrEch, ComEgrEeg, ComEgrEmi, ComAreCod,
ComCenCod, ComFluTip, ComFluCod) VALUES (@P1, @P2, @P3, @P4, @P5, @P6,
@P7, @P8, @P9, @P10, @P11, @P12, @P13, @P14, @P15, @P16, @P17, @P18,
@P19, @P20, 0, 0, '' '', 0, 0, 0, 0, '' '', '' '', 0, 0, '' '', 0, 0,
''17530101'', 0, 0, 0, 0, 0, 0, 0)', 0, 200701, 3, 2, 3, 0, 0, 0,
'Mar 5 2007 12:00AM', 9, 'EMP', 'Ene 3 2007 12:00AM', 'Ene 1 1753
12:00AM', 0, 0,
' ', 0, 0,
0.00, 0
select @P1

declare @P1 int
set @P15
declare @P2 int
set @P20150045
declare @P3 int
set @P3=4
declare @P4 int
set @P4=8
declare @P5 int
set @P5=-1
exec sp_cursorprepexec @P1 output, @P2 output, N'@P1 numeric(2,0),@P2
numeric(6,0),@P3 numeric(1,0),@P4 numeric(7,0)', N'SELECT SucCod,
ComAnoMes, ComTip, ComNum, ComDia, ComNumRef, ComEje, ComEst,
ComFchIng, ComMarUpd, EmpLla, ComFchMov, ComFchPrc, ComGru, ComMon,
ComGlo, ComUltLin, ComIteCod, ComEgrOtr, ComTotLin FROM COMPROBA
(UPDLOCK) WHERE SucCod = @P1 AND ComAnoMes = @P2 AND ComTip = @P3 AND
ComNum = @P4 ', @P3 output, @P4 output, @P5 output, 0, 200701, 3, 2
select @P1, @P2, @P3, @P4, @P5

exec sp_cursorfetch 180150045, 2, 1, 1

declare @P1 int
set @P16
declare @P2 int
set @P20150046
declare @P3 int
set @P3=4
declare @P4 int
set @P4=8
declare @P5 int
set @P5=-1
exec sp_cursorprepexec @P1 output, @P2 output, N'@P1 numeric(2,0),@P2
numeric(6,0),@P3 numeric(1,0),@P4 numeric(7,0),@P5 numeric(5,0)',
N'SELECT SucCod, ComAnoMes, ComTip, ComNum, ComLin, PlaCod, ComMmon,
ComDebOtr, ComHabOtr, ComTasCam, AreCod, CenCod, IteCod, FluTip,
FluCod, AnaTip, AnaCod, AnaSec, ComRefFch, ComGloDet, ComDebN,
ComHabN, ComDebO, ComHabO, ComDebNac, ComHabNac, ComRefNum, ComRefVto,
ComCorAud, ComFchMov FROM COMPROB1 (NOLOCK) WHERE SucCod = @P1 AND
ComAnoMes = @P2 AND ComTip = @P3 AND ComNum = @P4 AND ComLin = @P5
', @P3 output, @P4 output, @P5 output, 0, 200701, 3, 2, 0
select @P1, @P2, @P3, @P4, @P5

exec sp_cursorfetch 180150046, 2, 1, 1

declare @P1 int
set @P17
declare @P2 int
set @P20150047
declare @P3 int
set @P3=4
declare @P4 int
set @P4=8
declare @P5 int
set @P5=-1
exec sp_cursorprepexec @P1 output, @P2 output, N'@P1 char(9)',
N'SELECT PlaGru, PlaNom, PlaAreNeg, PlaCenCos, PlaCtaCte, PlaCueBlo,
PlaDocRef, PlaFchBlo, PlaFluEfe, PlaIteGas, PlaOtrMod, PlaUsoOtr,
PlaUsoRut, PlaCliCod, MonCod FROM PLACUED (NOLOCK) WHERE PlaCod > @P1 ', @P3 output, @P4 output, @P5 output, 'kjk '
select @P1, @P2, @P3, @P4, @P5

exec sp_cursorfetch 180150047, 2, 1, 1



On 5 mar, 17:22, "Carlos Sacristan" <nomail> wrote:
> Es complicado responderte... yo lo que haría sería generar una traza en
> el Profiler para capturar las sentencias que se envían al servidor (eventos
> RPC:Completed y SQL:BatchCompleted) y los bloqueos que se producen
> (típicamente Lock:Acquired y/o Lock:Deadlock)
>
> En cuanto al SELECT, es probable que el índice sea lo bastante
> restrictivo como para que SQL no tenga que bloquear exclusivamente toda la
> tabla, así que no creo que por ahí vayan los tiros... En cualquier caso, lo
> que nos va a sacar de dudas va a ser el Profiler
>
> "Manuel" escribió en el mensajenews:
> Gracias por tus comentarios Carlos
> Tenía incorporado el control de transacciones, pero por pruebas lo
> quitamos... necesitabamos ver en que punto del proceso se estaba
> provocando el problema, pues no nos esta ingresando nada asi que
> al estar fuera del bloque transaccional, incorporamos un proceso
> auditor tras el fin del proceso, para trabajar sobre los datos que
> estan a medias...
> luego que hayamos resuelto el problema, volveremos a incorporar el
> bloque transaccional...
>
> pero aun así, se sigue presentando el problema de los bloqueos lo cual
> me deja sin poder cargar los datos, de que forma sería posible
> salvarse esto?
> según la consulta que me genera la aplicación principal, que es la
> última tabla que se carga por medio de la aplicación en asp y
> trabajando sin el bloque transaccional no registra datos en ninguna de
> las otras tablas relacionadas, solo hace la actualización del control
> de los correlativos.
>
> en la instruccion
> SELECT SucCod, ComAnoMes, ComTip, ComNum, ComDia, ComNumRef, ComEje,
> ComEst, ComFchIng, ComMarUpd, EmpLla, ComFchMov, ComFchPrc, ComGru,
> ComMon, ComGlo, ComUltLin, ComIteCod, ComEgrOtr, ComTotLin FROM
> COMPROBA (UPDLOCK) WHERE SucCod = @P1 AND ComAnoMes = @P2 AND ComTip
> > > @P3 AND ComNum = @P4
>
> estos son los campos clave
> SucCod , ComAnoMes, ComTip, ComNum