¿Cuál podría ser la razón posible para este tipo de punto muerto? (no punto muerto en general)
Bloquear recursos del búfer de comunicación
¿Este sistema indicado tiene poca memoria y el conteo de búferes se agotó?
Error detallado
La transacción (ID de proceso 59) se bloqueó en los recursos del búfer de comunicación de bloqueo con otro proceso y se eligió como víctima del bloqueo. Vuelva a ejecutar la transacción.
Respuestas:
El mensaje completo que se ve comúnmente:
La transacción (ID de proceso 53) se bloqueó en el bloqueo | recursos de búfer de comunicación con otro proceso y ha sido elegido como la víctima de punto muerto. Vuelva a ejecutar la transacción.
Este tipo de bloqueo se ve comúnmente con las consultas de punto muerto que SQL Server ha ejecutado como paralelo, a veces denominadas "puntos muertos paralelos dentro de la consulta". He visto algunas declaraciones de que esto también señala que los recursos del sistema son bajos, lo que supongo que podría estar involucrado en un pequeño grado.
Una pauta general que he notado para determinar si es un punto muerto paralelo es cuando extrae el gráfico de punto muerto XML (que se puede hacer con la sesión system_health en 2008 y superior) notará diferentes ID de proceso que muestran el mismo bit de código dentro del pila de ejecución
Además, mirando la lista de recursos del gráfico de punto muerto y observando el tipo de evento de camarero. Por lo general, mostrarán "e_xxxxxx", o algo como esto quizás:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>
Para tratar de resolver el problema, se ofrecen varios caminos a seguir en línea y en libros. En general, empiezo mirando el plan de ejecución de la consulta / procedimiento y me concentro en las áreas que muestran ejecución paralela. Luego, a partir de ahí, intente ajustar la consulta primero y luego, como último recurso, puede comenzar a usar sugerencias de consulta.
La sugerencia de consulta más común que verá mencionada para resolver estos puntos muertos está implementando MAXDOP 1. Sin embargo, antes de hacerlo, puede verificar para ver qué nivel de servidor MAXDOP y Umbral de costos están configurados. El umbral de costo generalmente se establece en 5 de forma predeterminada y, para comenzar, me gusta aumentarlo a 35 o 40, si la consulta en cuestión tiene un bajo costo para esa sección de código, es posible que no necesite ejecutarse en paralelo. No me gusta mucho usar sugerencias de consulta MAXDOP, pero eso no significa que no tengan su lugar y propósito. Solo es mi opinión.