Mostrar un plan de ejecución estimado genera CXPACKET, PAGELATCH_SH y LATCH_EX [ACCESS_METHODS_DATASET_PARENT] espera

Estoy ejecutando Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) en una máquina virtual de 4 vCPU con max degree of parallelismset to 2y cost threshold for parallelismset to 50.

Por las mañanas, cuando intento mostrar un Plan de ejecución estimado para una consulta SELECT TOP 100 , me encuentro con esperas masivas y la operación para representar el plan estimado toma minutos, a menudo en el rango de 5 a 7 minutos. Nuevamente, esta no es la ejecución real de la consulta, es solo el proceso para mostrar un Plan de ejecución estimado .

sp_WhoIsActivemostrará PAGEIOLATCH_SHesperas o LATCH_EX [ACCESS_METHODS_DATASET_PARENT]esperas y cuando ejecuto el script WaitingTasks.sql de Paul Randal durante la operación, muestra CXPACKETesperas con los hilos de trabajo que muestran PAGEIOLATCH_SHesperas:

* campo de descripción del recurso = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Los subprocesos de trabajo parecen traer toda la statstabla a la memoria (ya que esos números de página y los números de página posteriores que se muestran desde el punto de consulta de Paul Randal vuelven a la clave agrupada para la statstabla). Una vez que el plan regresa, es básicamente instantáneo por el resto del día, incluso después de que veo la mayor parte de la statsdeserción de la tabla del caché con solo varios registros restantes (que supongo que se extrajeron debido a operaciones de búsqueda de consultas similares).

Esperaría este comportamiento inicial si la consulta se estuviera ejecutando realmente con un plan que utilizara operadores SCAN, pero ¿por qué lo hace al evaluar los planes de ejecución solo para llegar a un operador SEEK como se muestra en el plan vinculado anteriormente? ¿Qué puedo hacer (además de ejecutar esta declaración antes del horario de oficina para que mis datos se almacenen en la memoria caché adecuada) para ayudar a mejorar el rendimiento aquí? Supongo que un par de índices de cobertura sería beneficioso, pero ¿realmente garantizarían algún cambio en el comportamiento? Tengo que trabajar dentro de algunas limitaciones de la ventana de almacenamiento y mantenimiento aquí, y la consulta en sí se genera a partir de una solución del proveedor, por lo que cualquier otra sugerencia (además de una mejor indexación) sería bienvenida en este momento.

Parece que su solicitud de un plan de ejecución real activó las actualizaciones de estadísticas. Como mencionas que esto sucede por las mañanas, ¿imagino que hay un proceso nocturno que hace muchas modificaciones en las tablas involucradas?

Por lo tanto, SQL Server utiliza las estadísticas para crear el plan, alcanza el umbral de modificación y ejecuta actualizaciones automáticas de estadísticas como parte de la operación.

En el XML para el plan estimado que compartió, veo estas fechas de actualización para las estadísticas de esta mañana:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

Si estas son tablas muy grandes y ocupadas (parece probable que se basen en los porcentajes de muestreo), entonces no es demasiado sorprendente que las actualizaciones de estadísticas consuman mucha potencia.

Cuando veo tiempos de plan estimados largos en SSMS, es uno de los siguientes en orden de probabilidad:

1. El optimizador de consultas decidió que necesitaba crear o actualizar estadísticas.
2. El tamaño del plan estimado es muy grande (por ejemplo,> 10 MB) y simplemente le toma mucho tiempo a SSMS mostrarlo.
3. La compilación de consultas en sí tomó mucho tiempo debido al uso de la CPU para buscar un plan lo suficientemente bueno.
4. El servidor está bajo extrema presión. Por ejemplo, podría tener que esperar a que una puerta de enlace esté disponible.
5. Varios errores que conducen a tiempos de compilación extremadamente largos.

Para su situación, la respuesta es casi seguro que SQL Server está actualizando o creando estadísticas. Hay algunas pistas: el tamaño del plan de consulta es pequeño, el plan de consulta es relativamente simple con un bajo costo y la CPU de compilación es significativamente menor que el tiempo de compilación:

El nuevo contribuyente Josh Darnell también señaló una buena pista con el último tiempo actualizado para las estadísticas en el XML.

SQL Server 2019 presenta un nuevo tipo de espera, WAIT_ON_SYNC_STATISTICS_REFRESH , para cuando las consultas están esperando actualizaciones de estadísticas. Es mucho más fácil diagnosticar este problema en esa versión. Hasta entonces, solo tendrá que confiar en técnicas indirectas.

Las soluciones alternativas incluyen la actualización de estadísticas durante un período de mantenimiento o la habilitación de Actualización automática de estadísticas asíncrona para la base de datos. Comprenda las ramificaciones completas de esa opción antes de cambiarla. Los planes de consulta se crearán antes de actualizar las estadísticas en lugar de después de las actualizaciones de estadísticas. Para algunas cargas de trabajo que pueden ser una gran victoria. Para otros, puede hacer más daño que bien.