¿Cómo puedo demostrar que NOLOCK es la fuente de problemas de bloqueo?

No estoy tratando de comenzar una discusión de tipo Windows / Mac.

Personalmente, no necesito ningún convencimiento que NOLOCKno sea una buena idea como práctica reflexiva. Parece que cuando estás desarrollando todo debería ser útil, no reaccionario (/ amen)

Entonces ... el programador a cargo insiste en que NOLOCKes el camino a seguir. Se recomienda con todas las consultas ad-hoc y siempre que se consulte la producción. No he visto un procedimiento almacenado sin pistas nolock en cada tabla.

No quiero ser ese tipo que entra y les dice a todos que una creencia central está mal sin algo que lo respalde.

Simplemente mirando las sesiones de comentarios en las diferentes publicaciones del blog, enviar un enlace puede no ser suficiente. Creencias de larga data, etc. Algunas personas no están convencidas de que sea un problema. Ver: sección de comentarios debajo de cada publicación de blog de nolock que he leído.

Actualmente, algunos otros DBA están luchando con algunos misteriosos puntos muertos. ¿Cómo se determina si los NOLOCK son la fuente?

Se ha sugerido mirar XML desde trazas, etc., pero esto no indicará explícitamente que los puntos muertos están causando el problema, ¿verdad? Nunca he visto mensajes de error tan directos. ¿es eso cierto?

¿De qué otra forma podrían fijarse estos puntos muertos en esto?

Las declaraciones DDL como CREATEserían una pista. ¿Hay algún resultado al que pueda apuntar o algún dato que pueda encontrar que ayude a corroborar mi teoría antes de dar la alarma?

¿O estoy ejecutando marcas de seguimiento o eventos extendidos para identificar qué se está ejecutando cuando se producen los puntos muertos y luego deducir de las declaraciones DDL?

Al observar todas las diferentes formas en que los datos pueden confundirse con las sugerencias de nolock, parece un problema difícil de determinar de manera decisiva.

El arquitecto encargado de cómo insiste NOLOCKes el camino a seguir. Se recomienda con todas las consultas ad-hoc y siempre que se consulte la producción. No he visto un sproc sin pistas nolock en cada mesa.

Lamento escuchar eso. Esto es bastante universalmente considerado como un antipatrón entre los profesionales expertos de SQL Server, pero puede que no haya nada que pueda hacer para cambiar los hechos sobre el terreno si la práctica está realmente arraigada y se basa en las creencias sinceras y profundas de una persona. .

La pregunta dice que "enviar un enlace puede no ser suficiente", pero no está claro qué es lo que quieres. Podríamos escribir el argumento más convincente del mundo en una respuesta aquí, y aún se quedaría "enviándole un enlace". En última instancia, nadie aquí puede saber qué conjunto de argumentos tendrá éxito en su situación específica (si corresponde).

Sin embargo, lo siguiente cubre la mayoría de los puntos que algunas personas encuentran lo suficientemente persuasivos como para cambiar una práctica previamente común:

• Malos hábitos: poner en NOLOCKtodas partes por Aaron Bertrand
• NOLOCKSugerencia de SQL Server y otras ideas pobres Por David Lean (Microsoft)
• Leer el nivel de aislamiento no comprometido por mí
• Justifique NO usar la sugerencia (nolock) en cada consulta (preguntas y respuestas relacionadas aquí)

Aun así, es posible que no puedas 'ganar' esta batalla. He trabajado en un entorno que hizo esto, entendí los riesgos y las razones para no hacerlo, pero seguí con ello de todos modos. Estas eran personas brillantes y lógicas, pero al final era un entorno en el que no podría estar feliz trabajando.

Actualmente, algunos otros DBA están luchando con algunos misteriosos puntos muertos. ¿Cómo se determina que NOLOCKsson la fuente?

El patrón más habitual (quizás más frecuente en el pasado) es que NOLOCKse introducen sugerencias en un intento por reducir la incidencia de puntos muertos. Esto puede 'funcionar' ya que reducir la cantidad de bloqueos compartidos tomados naturalmente reduce las posibilidades de que se tomen bloqueos incompatibles, pero no es una buena solución al problema subyacente y viene con todas las advertencias mencionadas en la sección anterior.

Sin embargo, las NOLOCKsugerencias pueden introducir nuevas formas de punto muerto. El uso del aislamiento de lectura no confirmada puede eliminar una condición de bloqueo transitorio (resuelto cuando el recurso contendido está disponible) en un punto muerto no resuelto (donde ninguno de los camareros puede avanzar) simplemente porque la contención ahora ocurre en un punto diferente, donde, por ejemplo, las operaciones de escritura en un orden diferente superposición. Dave Ballantyne tiene un ejemplo aquí:

• Aumento de los puntos muertos con NOLOCK

Para obtener consejos más generales sobre cómo tratar con puntos muertos, recomiendo lo siguiente como punto de partida:

• La dificultad con los puntos muertos por Jeremiah Peschka

También debe familiarizarse con la documentación:

• Interbloqueo (y los tres subtemas allí)

Otros recursos útiles:

• SQL Server Deadlocks por ejemplo por Gail Shaw
• Solución de problemas de punto muerto por Bart Duncan