En SQL Server hay un hilo separado que periódicamente (predeterminado 5 segundos, intervalo inferior si se acaba de detectar un punto muerto) verifica una lista de esperas para cualquier ciclo. Es decir, identifica el recurso que está esperando un subproceso, luego encuentra el propietario de ese recurso y encuentra recursivamente qué recurso está esperando ese subproceso, identificando así los subprocesos que esperan los recursos de los demás.
Si se encuentra un punto muerto, se elige a una víctima para que la mate usando este algoritmo:
- Identifique los subprocesos que no se pueden matar (por ejemplo, un subproceso que revierte una transacción no se puede matar).
- Encuentra el hilo con la menor prioridad de punto muerto.
- Elija el que sea más barato para revertir, es decir, el que menos trabajo ha realizado hasta ahora.
Puede encontrar más información sobre la detección de punto muerto de servidores SQL aquí:
http://msdn.microsoft.com/en-us/library/ms178104.aspx
El propietario de la transacción / desarrollador de la aplicación es responsable de minimizar los riesgos de punto muerto y que deberían:
- Asegúrese de mantener las transacciones lo más cortas posible. Por ejemplo, no muestre un formulario de inicio de sesión después de comenzar una transacción y espere la entrada del usuario, en su lugar, recopile toda la información que necesita y luego ejecute la transacción.
- Use el nivel de aislamiento más bajo posible, por ejemplo, no configure serializable cuando solo quiera mostrar temporalmente algunos valores al usuario. Tenga en cuenta que establecer el nivel de aislamiento correcto es una ciencia en sí misma y está fuera de alcance en esta respuesta.
- Si es víctima de un punto muerto, es decir, obtiene el error # 1205, vuelva a ejecutar su transacción de manera transparente para su usuario. Dado que la otra transacción, que compite, ahora con suerte ha adquirido los recursos que estaba esperando y terminó, es poco probable que encuentre el mismo punto muerto nuevamente.