Bloqueos

Muchas gracias por esta información, bueno, ahora que puedo ver el log qué
hago si encuentro estas palabras?, es decir, qué puedo hacer para evitar que
esto pase, ayer corrí una traza y me doy cuenta de lo que dices, es verdad,
son operaciones de lectura contra operaciones de borrado lo que me estan
causando estos bloqueos, pero qué puedo hacer para evitar que pase?, si
igual necesito borrar y leer, bueno mejor dicho, unos usuarios estan leyendo
y otros borrando, diferentes registros pero lo hacen, cómo puedo mejorar
esto?

Mil gracias por tus respuestas,


"Mauro" escribió en el mensaje
news:eYpq5$

es facil, en la carpeta de instalacion del sql vas a encontrar una carpeta
log con todos los logs, el corriente es el que no tiene un numero al
final.
lo abres en un editor que puede ser el notepad o el vim si es muy grande y
buscas las palabras
deadlock was found
o
printing deadlock information
si los hay podras ver los procesos intervinientes sus consultas y el
codigo
de los objetos en disputa que luego lo
puedes sacar utilizando una consulta
"Alexander Gomez" wrote in message
news:

te agradecería que me dijeras cómo reviso el log, por que de eso si no

tengo

ni idea
"Mauro" escribió en el mensaje
news:
> los deadlocks los detectas mejor levantando estas banderas:
> dbcc traceon(3604)
> dbcc traceon(3605)
> dbcc traceon(1204)
> dbcc traceon(1205)
> dbcc tracestatus(-1)
>
> luego en el log del sql vas a ver los resultados
> analizarlos es un poco complejo pero si es necesario te digo como
> con el profiler puedes detectar las consultas que comienzan y no

terminan

> y
> que dejan tomados los recursos(indices,rows, hasta tablas enteras)
> por lo general los problemas se dan en los indices en operaciones de
> lectura
> contra operaciones de borrado o modificacion.
>
> "Alexander Gomez" wrote in message
> news:%
>> sip, solo me pasó despues de que instale el SP4 por que hasta el SP3

todo

>> andaba muy bien,
>> si no estoy mal los deadlocks y timeouts se detectan por el profiler?
>> qué haría con esta información?
>>
>> "Mauro" escribió en el mensaje
>> news:%23o48R%
>> > Pueden ser muchas cosas, habria que ver que trafic y que recursos
>> > tienen
>> > los
>> > procesos que te estan bloqueando y por que, lo raro es que te paso

solo

>> > con el SP4 y con el SP3
>> > sabes detectar deadlocks y timeouts?
>> >
>> > "Alexander Gomez" wrote in message
>> > news:
>> >> Hola a todos!!
>> >>
>> >> desde que instalé el service pack 4 de sql server 2000, tengo
>> >> problemas
>> > por
>> >> que al eliminar registros de unas tablas, (por medio de la
>> >> aplicación),
>> > los
>> >> procesos son bloqueados por cualquier persona que tenga abierta la
>> >> aplicacion.
>> >>
>> >> Ustedes me pueden dar luces?
>> >>
>> >> Mil gracias desde ya
>> >>
>> >>
>> >
>> >
>>
>>
>
>

en ese caso tenes que ver la forma en la que estas leyendo/borrando.
por ejemplo hace poco yo solucione algo parecido aqui.

empecemos por que el borrado es una operacion que necesita tomar los
recursos exclusivamente
,es decir que no permitira que nadie haga otra operacion sobre los registros
que esta tomando(excepto una lectura sucia)
Seguramente tu proceso de borrado no debe estar basado en indices primarios
sino en una clausula where algo>otroalgo
u otra. por lo que para ver que filas cumplen con la condicion necesitara
bloquear la mayoria de las filas hasta saber cuales va a borrar.

lo que puedes hacer para mejorar esto es, primero guardar los id de los
registros que vas a borrar en una variable de texto o en una tabla temporal
haciendo un select con lectura sucia o compartido, de este modo los otros
selects de otros procesos pueden seguir leyendo.
luego cuando hayas guardado ejecutas el delete pero tomando como parametro
el id ej:
delete from table where id in (select id from #table)
de esta manera el delete sera mas rapido y solo bloqueara los registros que
necesita borrar.

otra opcion es hacer que los otros procesos hagan lecturas sucias ej select
* from tabla with (nolock)
esto provoca leer las transacciones no finalizadas, pero hay que tener mucho
cuidado y no es recomendable en todos los casos
por ejemplo cuando vas a leer alances o stock. Ya que puede devolver
informacion erronea.

suerte.

si la consulta que va a hacer el borrado es una consulta basada en
"Alexander Gomez" wrote in message
news:

Muchas gracias por esta información, bueno, ahora que puedo ver el log qué
hago si encuentro estas palabras?, es decir, qué puedo hacer para evitar

que

esto pase, ayer corrí una traza y me doy cuenta de lo que dices, es

verdad,

son operaciones de lectura contra operaciones de borrado lo que me estan
causando estos bloqueos, pero qué puedo hacer para evitar que pase?, si
igual necesito borrar y leer, bueno mejor dicho, unos usuarios estan

leyendo

y otros borrando, diferentes registros pero lo hacen, cómo puedo mejorar
esto?

Mil gracias por tus respuestas,


"Mauro" escribió en el mensaje
news:eYpq5$
> es facil, en la carpeta de instalacion del sql vas a encontrar una

carpeta

> log con todos los logs, el corriente es el que no tiene un numero al
> final.
> lo abres en un editor que puede ser el notepad o el vim si es muy grande

y

> buscas las palabras
> deadlock was found
> o
> printing deadlock information
> si los hay podras ver los procesos intervinientes sus consultas y el
> codigo
> de los objetos en disputa que luego lo
> puedes sacar utilizando una consulta
> "Alexander Gomez" wrote in message
> news:
>> te agradecería que me dijeras cómo reviso el log, por que de eso si no
> tengo
>> ni idea
>> "Mauro" escribió en el mensaje
>> news:
>> > los deadlocks los detectas mejor levantando estas banderas:
>> > dbcc traceon(3604)
>> > dbcc traceon(3605)
>> > dbcc traceon(1204)
>> > dbcc traceon(1205)
>> > dbcc tracestatus(-1)
>> >
>> > luego en el log del sql vas a ver los resultados
>> > analizarlos es un poco complejo pero si es necesario te digo como
>> > con el profiler puedes detectar las consultas que comienzan y no
> terminan
>> > y
>> > que dejan tomados los recursos(indices,rows, hasta tablas enteras)
>> > por lo general los problemas se dan en los indices en operaciones de
>> > lectura
>> > contra operaciones de borrado o modificacion.
>> >
>> > "Alexander Gomez" wrote in message
>> > news:%
>> >> sip, solo me pasó despues de que instale el SP4 por que hasta el SP3
> todo
>> >> andaba muy bien,
>> >> si no estoy mal los deadlocks y timeouts se detectan por el

profiler?

>> >> qué haría con esta información?
>> >>
>> >> "Mauro" escribió en el mensaje
>> >> news:%23o48R%
>> >> > Pueden ser muchas cosas, habria que ver que trafic y que recursos
>> >> > tienen
>> >> > los
>> >> > procesos que te estan bloqueando y por que, lo raro es que te paso
> solo
>> >> > con el SP4 y con el SP3
>> >> > sabes detectar deadlocks y timeouts?
>> >> >
>> >> > "Alexander Gomez" wrote in message
>> >> > news:
>> >> >> Hola a todos!!
>> >> >>
>> >> >> desde que instalé el service pack 4 de sql server 2000, tengo
>> >> >> problemas
>> >> > por
>> >> >> que al eliminar registros de unas tablas, (por medio de la
>> >> >> aplicación),
>> >> > los
>> >> >> procesos son bloqueados por cualquier persona que tenga abierta

la

>> >> >> aplicacion.
>> >> >>
>> >> >> Ustedes me pueden dar luces?
>> >> >>
>> >> >> Mil gracias desde ya
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Oye muchas gracias, ya implemnté el eliminado de esa forma y estoy esperando
a ver que pasa...
Muchas gracias

"Mauro" escribió en el mensaje
news:

en ese caso tenes que ver la forma en la que estas leyendo/borrando.
por ejemplo hace poco yo solucione algo parecido aqui.

empecemos por que el borrado es una operacion que necesita tomar los
recursos exclusivamente
,es decir que no permitira que nadie haga otra operacion sobre los
registros
que esta tomando(excepto una lectura sucia)
Seguramente tu proceso de borrado no debe estar basado en indices
primarios
sino en una clausula where algo>otroalgo
u otra. por lo que para ver que filas cumplen con la condicion necesitara
bloquear la mayoria de las filas hasta saber cuales va a borrar.

lo que puedes hacer para mejorar esto es, primero guardar los id de los
registros que vas a borrar en una variable de texto o en una tabla
temporal
haciendo un select con lectura sucia o compartido, de este modo los otros
selects de otros procesos pueden seguir leyendo.
luego cuando hayas guardado ejecutas el delete pero tomando como parametro
el id ej:
delete from table where id in (select id from #table)
de esta manera el delete sera mas rapido y solo bloqueara los registros
que
necesita borrar.

otra opcion es hacer que los otros procesos hagan lecturas sucias ej
select
* from tabla with (nolock)
esto provoca leer las transacciones no finalizadas, pero hay que tener
mucho
cuidado y no es recomendable en todos los casos
por ejemplo cuando vas a leer alances o stock. Ya que puede devolver
informacion erronea.

suerte.

si la consulta que va a hacer el borrado es una consulta basada en
"Alexander Gomez" wrote in message
news:

Muchas gracias por esta información, bueno, ahora que puedo ver el log
qué
hago si encuentro estas palabras?, es decir, qué puedo hacer para evitar

que

esto pase, ayer corrí una traza y me doy cuenta de lo que dices, es

verdad,

son operaciones de lectura contra operaciones de borrado lo que me estan
causando estos bloqueos, pero qué puedo hacer para evitar que pase?, si
igual necesito borrar y leer, bueno mejor dicho, unos usuarios estan

leyendo

y otros borrando, diferentes registros pero lo hacen, cómo puedo mejorar
esto?

Mil gracias por tus respuestas,


"Mauro" escribió en el mensaje
news:eYpq5$
> es facil, en la carpeta de instalacion del sql vas a encontrar una

carpeta

> log con todos los logs, el corriente es el que no tiene un numero al
> final.
> lo abres en un editor que puede ser el notepad o el vim si es muy
> grande

y

> buscas las palabras
> deadlock was found
> o
> printing deadlock information
> si los hay podras ver los procesos intervinientes sus consultas y el
> codigo
> de los objetos en disputa que luego lo
> puedes sacar utilizando una consulta
> "Alexander Gomez" wrote in message
> news:
>> te agradecería que me dijeras cómo reviso el log, por que de eso si no
> tengo
>> ni idea
>> "Mauro" escribió en el mensaje
>> news:
>> > los deadlocks los detectas mejor levantando estas banderas:
>> > dbcc traceon(3604)
>> > dbcc traceon(3605)
>> > dbcc traceon(1204)
>> > dbcc traceon(1205)
>> > dbcc tracestatus(-1)
>> >
>> > luego en el log del sql vas a ver los resultados
>> > analizarlos es un poco complejo pero si es necesario te digo como
>> > con el profiler puedes detectar las consultas que comienzan y no
> terminan
>> > y
>> > que dejan tomados los recursos(indices,rows, hasta tablas enteras)
>> > por lo general los problemas se dan en los indices en operaciones de
>> > lectura
>> > contra operaciones de borrado o modificacion.
>> >
>> > "Alexander Gomez" wrote in message
>> > news:%
>> >> sip, solo me pasó despues de que instale el SP4 por que hasta el
>> >> SP3
> todo
>> >> andaba muy bien,
>> >> si no estoy mal los deadlocks y timeouts se detectan por el

profiler?

>> >> qué haría con esta información?
>> >>
>> >> "Mauro" escribió en el mensaje
>> >> news:%23o48R%
>> >> > Pueden ser muchas cosas, habria que ver que trafic y que recursos
>> >> > tienen
>> >> > los
>> >> > procesos que te estan bloqueando y por que, lo raro es que te
>> >> > paso
> solo
>> >> > con el SP4 y con el SP3
>> >> > sabes detectar deadlocks y timeouts?
>> >> >
>> >> > "Alexander Gomez" wrote in message
>> >> > news:
>> >> >> Hola a todos!!
>> >> >>
>> >> >> desde que instalé el service pack 4 de sql server 2000, tengo
>> >> >> problemas
>> >> > por
>> >> >> que al eliminar registros de unas tablas, (por medio de la
>> >> >> aplicación),
>> >> > los
>> >> >> procesos son bloqueados por cualquier persona que tenga abierta

la

>> >> >> aplicacion.
>> >> >>
>> >> >> Ustedes me pueden dar luces?
>> >> >>
>> >> >> Mil gracias desde ya
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>