¿Cómo se detectan e informan los puntos muertos en un RDBMS?


8

Me dieron esta pregunta tipo ensayo durante una entrevista pero no obtuve el trabajo. La pregunta completa fue la siguiente:

¿Cómo se detectan e informan los puntos muertos en un RDBMS? ¿De qué son responsables el propietario de la transacción y el desarrollador de la aplicación para garantizar en los escenarios de detección y prevención?

Respuestas:


13

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:

  1. Identifique los subprocesos que no se pueden matar (por ejemplo, un subproceso que revierte una transacción no se puede matar).
  2. Encuentra el hilo con la menor prioridad de punto muerto.
  3. 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:

  1. 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.
  2. 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.
  3. 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.

4. Adquiera recursos y realice patrones de actualización / eliminación / inserción en el mismo orden de manera consistente en toda la aplicación.
ErikE

3
@ErikE con frecuencia no es posible / factible "realizar patrones de actualización / eliminación / inserción en el mismo orden de manera consistente en toda la aplicación", aunque este cuestionable consejo es muy popular en la Web. Detalles aquí: sqlblog.com/blogs/alexander_kuznetsov/archive/2010/01/15/…
AK

1
Buenos puntos. Pero sigo pensando que el esfuerzo vale la pena, siempre y cuando uno no tenga la ilusión de que siempre será posible o siempre solucionará el problema. Lo principal / secundario es interesante, ¿qué tal si elimina en cascada o adquiere un bloqueo de actualización en las filas principales primero? Y si haces fusiones sin MERGE, ¿por qué no ser consistente? Borro-> actualizar-> insertar personalmente.
ErikE

1
@AlexKuznetsov: No es una solución de solución, pero no debe descartarse. He reducido (no eliminado) callejones sin salida esta manera sin embargo: a través de análisis estático de código pasan con frecuencia que no todos los días o callejón sin salida 7. Yo sugeriría "optimización prematura" se aplica etc
GBN

No estoy de acuerdo con la recomendación número 3. Cuando volvemos a intentar después de puntos muertos, es muy probable que sobrescribamos los cambios de otros procesos. Debemos ser conscientes de que es muy probable que alguien más haya modificado los datos que pretendíamos modificar. Especialmente si todos los lectores se ejecutan bajo aislamiento de instantáneas, los lectores no pueden participar en puntos muertos, lo que significa que todas las partes involucradas en un punto muerto son escritores, modificados o intentaron modificar los mismos datos. Si solo detectamos la excepción y reintentamos automáticamente, podemos sobrescribir los cambios de otra persona. Esto se llama actualizaciones perdidas, y esto generalmente es incorrecto.
AK
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.