Bloqueo Procesos

mira esto es lo q dice el manual (creo q es tu caso por eso lo posteo,
quizas me equivoque)

Comprender y evitar los bloqueos
Los bloqueos se producen cuando una conexión de una aplicación mantiene un
bloqueo y una segunda conexión requiere un tipo de bloqueo que entra en
conflicto con el anterior. Esto obliga a la segunda conexión a esperar,
bloqueada por la primera. Una conexión puede bloquear otra conexión,
independientemente de si procede de la misma aplicación o de aplicaciones
diferentes de distintos equipos cliente.



Nota Es posible que algunas de las acciones que necesitan protección por
bloqueo no sean obvias, como los bloqueos en las tablas e índices del
catálogo del sistema.


La mayoría de los problemas de bloqueo se producen debido a que un único
proceso mantiene bloqueos durante un período largo de tiempo, lo que causa
una cadena de procesos bloqueados que esperan a otros procesos para realizar
su bloqueo.

Los escenarios comunes de los bloqueos son:

a.. Enviar consultas con tiempos largos de ejecución.
La ejecución de una consulta de larga duración puede bloquear otras
consultas. Por ejemplo, una operación DELETE o UPDATE que afecte a muchas
filas puede adquirir muchos bloqueos que, se concentren o no en un bloqueo
de tabla, bloquean a otras consultas. Por este motivo, generalmente no
deseará mezclar consultas de ayuda para la toma de decisiones de larga
duración y consultas de procesamiento de transacciones en línea (OLTP) en la
misma base de datos. La solución consiste en buscar maneras de optimizar la
consulta, cambiando los índices, descomponiendo una consulta larga y
compleja en varias consultas más sencillas o ejecutando la consulta durante
horas libres o en un equipo independiente.

Un motivo por el que la ejecución de una consulta pueden ser de larga
duración y, por tanto, puede causar bloqueos, es el uso incorrecto de
cursores. Los cursores pueden ser un método conveniente de desplazarse por
un conjunto de resultados, pero su uso puede ser más lento que las consultas
orientadas a conjuntos.

b.. Cancelar las consultas que no se han confirmado o deshecho.
Esto puede ocurrir si la aplicación cancela una consulta; por ejemplo, al
utilizar la función sqlcancel de conectividad abierta de bases de datos
(ODBC) sin tampoco emitir el número requerido de instrucciones ROLLBACK y
COMMIT. Cancelar la consulta no deshace ni confirma automáticamente la
transacción. Todos los bloqueos adquiridos en la transacción se retienen una
vez cancelada la consulta. Las aplicaciones deben administrar correctamente
los niveles de anidamiento de las transacciones confirmando o deshaciendo
las transacciones canceladas.

c.. Aplicaciones que no procesan todos los resultados hasta el final.
Después de enviar una consulta al servidor, todas las aplicaciones deben
recuperar inmediatamente todas las filas de resultados hasta el final. Si
una aplicación no recupera todas las filas de resultados, pueden quedar
bloqueos en las tablas que afecten a otros usuarios. Si utiliza una
aplicación que envía de forma transparente instrucciones Transact-SQL al
servidor, la aplicación debe recuperar todas las filas de resultados. Si no
las recupera (y no se puede configurar para hacerlo), es posible que no
pueda resolver la situación de bloqueo. Para evitar el problema, puede
restringir estas aplicaciones a bases de datos de informes o de ayuda a la
toma de decisiones.

d.. Interbloqueos cliente-servidor distribuidos.
A diferencia de un interbloqueo convencional, Microsoft® SQL ServerT 2000
no puede detectar automáticamente un interbloqueo distribuido. Se puede
producir un interbloqueo distribuido entre el cliente y el servidor si la
aplicación abre más de una conexión a SQL Server y envía una consulta
asincrónicamente.

Por ejemplo, un único subproceso de una aplicación cliente tiene dos
conexiones abiertas. Inicia una transacción de forma asincrónica y emite una
consulta sobre la primera conexión. A continuación, la aplicación inicia
otra transacción, emite una consulta sobre otra conexión y espera los
resultados. Cuando SQL Server devuelve los resultados de una de las
conexiones, la aplicación comienza a procesarlos. La aplicación procesa los
resultados hasta que no hay más resultados disponibles debido a que la
consulta que genera los resultados está bloqueada por la consulta ejecutada
sobre la otra conexión. En este punto, la primera conexión se bloquea y
espera indefinidamente a recibir más resultados para procesarlos. La segunda
conexión no está bloqueada por un bloqueo, pero intenta devolver resultados
a la aplicación. Sin embargo, debido a que la aplicación está bloqueada en
espera de los resultados de la primera conexión, no se procesan los
resultados de la segunda conexión.

Para evitar este problema, tiene las siguientes opciones:

a.. Establecer un tiempo de espera para cada consulta.


b.. Establecer un tiempo de espera de bloqueo para cada consulta. Para
obtener más información, consulte Personalizar el tiempo de espera de los
bloqueos.


c.. Una conexión enlazada. Para obtener más información, consulte
Utilizar conexiones enlazadas.
SQL Server es, esencialmente, un títere de la aplicación cliente. La
aplicación cliente tiene un control casi total sobre (y es la responsable
de) los bloqueos adquiridos en el servidor. Aunque el administrador de
bloqueos de SQL Server utiliza automáticamente bloqueos para proteger las
transacciones, esta situación se debe al tipo de consulta enviado desde la
aplicación cliente y a la forma en que se procesan los resultados. Por
tanto, la solución de la mayor parte de los problemas de bloqueo requiere
que se inspeccione la aplicación cliente.

Un problema de bloqueos suele requerir que se inspeccionen las instrucciones
SQL exactas que envía la aplicación y el comportamiento exacto de la
aplicación en cuanto a la administración de conexiones, el procesamiento de
todas las filas de resultados, etc. Si la herramienta de desarrollo no
permite ejercer un control explícito de la administración de la conexión, el
tiempo de espera de las consultas, el procesamiento de los resultados, etc.,
es posible que no pueda resolver los problemas de bloqueo.

Las directrices para diseñar aplicaciones que eviten bloqueos son:

a.. No utilizar ni diseñar una aplicación que permita a los usuarios
llenar cuadros de edición que generen una consulta de ejecución de larga
duración. Por ejemplo, no utilice ni diseñe una aplicación que pida al
usuario que especifique datos y que permita dejar determinados campos en
blanco o escribir caracteres comodín. Esto puede causar que la aplicación
envíe una consulta cuyo tiempo de ejecución sea excesivo y, por tanto,
provoque un problema de bloqueo.


b.. No utilizar ni diseñar una aplicación que permita al usuario
especificar datos en una transacción.


c.. Permitir la cancelación de la consulta.


d.. Utilizar un tiempo de espera de la consulta o del bloqueo para impedir
que una consulta se descontrole y evitar los interbloqueos distribuidos.


e.. Recuperar inmediatamente todas las filas de resultados hasta el final.


f.. Hacer que las transacciones sean lo más cortas posible.


g.. Controlar explícitamente la administración de la conexión.


h.. Probar exhaustivamente la aplicación con toda la carga de usuarios
simultáneos prevista.

Accotto Maximiliano Damian
Fundicion San Cayetano S.A
4002 - 4010
Gerente de Sistemas

"Patricia Rincon" escribió en el
mensaje news:02f301c3aa1e$d356fca0$
Hola a todos

Tengo un aplicativo en el que trabajan varios usuarios de
forma concurrente y en ocasiones se presentan bloqueos de
hasta 10 minutos.


Cuando hago un sp_who encuentro que hay muchos procesos
bloqueados por un solo proceso A y este proceso A está
realizando un Update. Verifico el proceso A y encuentro
que está bloqueado por un proceso B. El proceso B esta
realizando un Select.

No comprendo como un Select puede bloquear la bd.

Lamentablemente solo tengo acceso a los trace de SQL , a
los fuentes del aplicativo no.


Esta es una muestra de lo que me arroja el Sp_who:

SPID BLKBY COMMAND

456 145 SELECT
481 145 SELECT
483 145 SELECT
383 145 SELECT
406 145 UPDATE
435 145 SELECT
283 145 SELECT
299 145 SELECT
218 145 SELECT
237 145 SELECT
145 494 UPDATE
494 0 SELECT

Mil gracias a todos


begin 666 note.gif
M1TE&.#EA# `+`(#_`(2&`,# P"'Y! $```$`+ `````,``L`0 (:C(\(H'S[
68%R0&ED;M7,'[%S2YW#1)VJ;4P``.P``
`
end