Por lo tanto, en SQL Server 2016, las actualizaciones de estadísticas que usan el modo de muestra ahora se ejecutan en paralelo con el nivel de compatibilidad 130, y así es como funciona de forma predeterminada, para todas las actualizaciones de estadísticas automáticas y manuales. Esto se explica brevemente aquí:
- Adiciones al optimizador de consultas en SQL Server 2016
(También se ha actualizado la documentación, tanto el tema Nivel de compatibilidad como el tema ACTUALIZAR ESTADÍSTICAS.)
Sin embargo, ¿no sería bueno poder especificar cuántas CPU se pueden usar realmente para estas operaciones (además de permitir el límite de 16)? Creo que poder limitar esto a 4 u 8 sería algo obvio y lógico para apoyar. Especialmente para los clientes que ejecutan sistemas con 16 núcleos o menos, o varias instancias en una caja, que no pueden confiar en funciones empresariales como Resource Governor (que la mayoría de los clientes empresariales tampoco se molestarían en usar, en mi humilde opinión).
La justificación comercial para esto sería la misma que la utilizada para agregar soporte MAXDOP REBUILD, DBCC CHECKDB y su familia de operaciones de mantenimiento, etc. Desea evitar que este tipo de actividad se apodere de todos los núcleos, sin hacer algo tan drástico como desactivar las actualizaciones automáticas o usar MAXDOP en toda la instancia, porque no todos tienen el lujo de ventanas de mantenimiento.
Y en este caso, MAXDOP en toda la instancia no ayudará de todos modos , porque SQL Server 2016 RTM tiene un error en el que se ignora MAXDOP para actualizaciones de estadísticas muestreadas. Próximamente se solucionará, pero pensé que deberías saberlo; si esto le está causando un problema, una opción es usar un nivel de compatibilidad más bajo.
Pero reiteraré algo que digo a menudo:el nivel de compatibilidad se está llenando demasiado. Si quiero estadísticas de muestras paralelas en mi base de datos pero tengo suficientes regresiones de estimación de cardinalidad para requerir el CE anterior, tengo que elegir una u otra.
Y otra cosa:el gobernador de recursos es excesivo para este caso de uso, y limitar el uso del núcleo de las actualizaciones de estadísticas no debería ser realmente una función empresarial (al igual que REBUILD y CHECKDB mencionados anteriormente). No me digan que RG es una alternativa aceptable, porque solo es posible para los usuarios con Enterprise Edition *y* clasificaciones de carga de trabajo que deberían estar limitadas por MAXDOP todo el tiempo . Debería poder limitar esto por una operación específica (o, digamos, solo para mis tablas más grandes/problemáticas), no restringiendo la sesión completa de un inicio de sesión.
Cómo me gustaría que lo hicieran
Idealmente, podríamos establecer esto en el nivel de la base de datos, usando la nueva opción CONFIGURACIÓN DEL ÁMBITO DE LA BASE DE DATOS, y en el nivel de la declaración, usando la sintaxis familiar de OPCIÓN (MAXDOP n). El nivel de declaración ganaría, y cualquier actualización de estadísticas de modo de muestra (incluidas las automáticas) sin una sugerencia MAXDOP explícita volvería a la configuración de nivel de base de datos. Esto me permitiría establecer un MAXDOP de 4, por ejemplo, para todas las actualizaciones de estadísticas automáticas que ocurren en momentos impredecibles, pero 8 o 16 para operaciones manuales en ventanas de mantenimiento conocidas. Como un ejemplo.
Si desea votar por esto, consulte el siguiente elemento de conexión y agregue una justificación comercial para esto (al estilo de Michael Campbell):
- Conectar #628971:agregar el parámetro MAXDOP para actualizar estadísticas
Por supuesto, ese elemento ha estado allí desde 2010, por lo que no se menciona en absoluto la vía CONFIGURACIÓN DEL ALCANCE DE LA BASE DE DATOS, por lo que también dejé un comentario.
Mientras tanto, si desea deshabilitar el paralelismo para el modo de muestra, hay un indicador de rastreo para volver efectivamente al comportamiento anterior (también puede hacerlo volviendo a un nivel de compatibilidad inferior a 130, pero no lo recomiendo porque afecta a muchas otras cosas). Actualizaré este espacio cuando me hayan dado el visto bueno para divulgar públicamente la marca de rastreo, pero en este momento, Microsoft se lo está guardando con fuerza.
