Manual de estimación de niveles de compatibilidad y cardinalidad

Introducción

Entre 1998 y principios de 2014, SQL Server usó un estimador de cardinalidad (CE), pero introdujo un nuevo nivel de compatibilidad de base de datos con cada nueva versión principal de SQL Server (con la excepción de SQL Server 2008 R2). Los niveles de compatibilidad nativa para SQL Server se muestran por versión principal de SQL Server en la Tabla 1:

Tabla 1:Versiones de SQL Server y niveles de compatibilidad nativa

Entre SQL Server 7.0 y SQL Server 2012, no hubo conexión entre el nivel de compatibilidad de una base de datos y el estimador de cardinalidad que usarían las consultas en esa base de datos. Esto se debe a que solo había un estimador de cardinalidad, que recibió una actualización importante en 1998. El nivel de compatibilidad de una base de datos solo se usaba para la compatibilidad funcional hacia atrás y para habilitar/deshabilitar algunas características nuevas en cada nueva versión de SQL Server (consulte este Respuesta de Stack Exchange para ejemplos de cómo cambió el comportamiento entre 80 y 90, probablemente el cambio más disruptivo). A diferencia de la versión de archivo de una base de datos de SQL Server, puede cambiar el nivel de compatibilidad de una base de datos en cualquier momento, a cualquier nivel de compatibilidad admitido, con un simple comando ALTER DATABASE.

De forma predeterminada, si creaste un nuevo base de datos en SQL Server 2012, el nivel de compatibilidad se establecería en 110, pero podría cambiarlo a un nivel anterior si lo desea. Si restauró una copia de seguridad de la base de datos de una instancia de SQL Server 2008 a una instancia de SQL Server 2012, actualizaría la versión del archivo de la base de datos, pero dejaría el nivel de compatibilidad donde había estado en la instancia de SQL Server 2008 (a menos que fuera 80, lo que actualizarse a 90, la versión mínima admitida por SQL Server 2012). Además de conocer la diferencia fundamental entre la versión del archivo de una base de datos y el nivel de compatibilidad de una base de datos, la mayoría de los administradores de bases de datos y desarrolladores no tenían que preocuparse mucho por los niveles de compatibilidad de la base de datos antes del lanzamiento de SQL Server 2014. En muchos casos, la mayoría de las bases de datos nunca cambiaron sus niveles de compatibilidad después de una migración a una nueva versión de SQL Server. Por lo general, esto no causaba ningún problema a menos que realmente necesitara una nueva función o comportamiento que cambiara en el último nivel de compatibilidad de la base de datos.

Cambios en SQL Server 2014

Esta antigua situación cambió radicalmente con el lanzamiento de SQL Server 2014. SQL Server 2014 introdujo un "nuevo" estimador de cardinalidad que estaba habilitado de forma predeterminada cuando una base de datos estaba en el nivel de compatibilidad 120. En el documento técnico clásico, "Optimización de sus planes de consulta con el Estimador de cardinalidad de SQL Server 2014", Joe Sack explica los antecedentes y el comportamiento de este cambio en abril de 2014. En muchos casos, la mayoría de sus consultas se ejecutaron más rápido al usar la nueva cardinalidad. estimador, pero era bastante común encontrarse con algunas consultas que tenían importantes regresiones de rendimiento con el nuevo estimador de cardinalidad. Si eso sucediera, SQL Server 2014 no tenía tantas opciones para aliviar los problemas de rendimiento causados ​​por el nuevo CE. El documento técnico de Joe cubre esas opciones con gran detalle, pero esencialmente, estaba limitado a marcas de rastreo a nivel de instancia o sugerencias de consulta a nivel de consulta para controlar qué estimador de cardinalidad usaba el optimizador de consultas, a menos que quisiera volver al nivel de compatibilidad 110 o inferior. .

Cambios en SQL Server 2016

SQL Server 2016 introdujo opciones de configuración en el ámbito de la base de datos, que le brindan la capacidad de controlar algunos comportamientos que antes se configuraban en el nivel de instancia, mediante un comando ALTER DATABASE SCOPED CONFIGURATION. En SQL Server 2016, estas opciones incluían MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING y QUERY_OPTIMIZER_HOTFIXES. También había una opción CLEAR PROCEDURE_CACHE que le permitía borrar todo el caché del plan para una sola base de datos.

Las más relevantes en este contexto son las opciones de configuración del ámbito de la base de datos LEGACY_CARDINALITY ESTIMATION y QUERY_OPTIMIZER_HOTFIXES. LEGACY_CARDINALITY ESTIMATION habilita el CE heredado independientemente de la configuración del nivel de compatibilidad de la base de datos. Es equivalente al indicador de seguimiento 9481, pero solo afecta a la base de datos en cuestión, no a toda la instancia. Le permite establecer el nivel de compatibilidad de la base de datos en 130 para obtener una serie de beneficios funcionales y de rendimiento, pero aún así usar la base de datos CE heredada en toda la base de datos (a menos que se anule con una sugerencia de consulta a nivel de consulta).

La opción QUERY_OPTIMIZER_HOTFIXES es equivalente al indicador de seguimiento 4199 en el nivel de la base de datos. SQL Server 2016 habilitará todas las revisiones del optimizador de consultas antes SQL Server 2016 RTM cuando usa el nivel de compatibilidad de base de datos 130 (sin habilitar el indicador de seguimiento 4199). Si habilita TF 4199 o habilita QUERY_OPTIMIZER_HOTFIXES, también obtendrá todas las revisiones del optimizador de consultas que se publicaron después SQL Server 2016 RTM.

SQL Server 2016 SP1 también introdujo las sugerencias de consulta USE HINT que son más fáciles de usar, comprender y recordar que las sugerencias de consulta QUERYTRACEON anteriores. Esto le brinda un control aún más detallado sobre el comportamiento del optimizador que está relacionado con el nivel de compatibilidad de la base de datos y la versión del estimador de cardinalidad que se está utilizando. Puede consultar sys.dm_exec_valid_use_hints para obtener una lista de nombres de USE HINT válidos para la compilación exacta de SQL Server que está ejecutando.

Cambios en SQL Server 2017

La nueva función de procesamiento de consultas adaptable se agregó en SQL Server 2017 y está habilitada de manera predeterminada cuando usa el nivel de compatibilidad de base de datos 140.

Microsoft está tratando de alejarse de la antigua terminología de "Nuevo CE" y "Antiguo CE", ya que en realidad hay cambios y correcciones para la optimización de consultas en cada nueva versión principal de SQL Server. Debido a esto, ya no existe un solo “Nuevo CE”. En su lugar, Microsoft quiere referirse a CE70 (CE predeterminado para SQL Server 7.0 a SQL Server 2012), CE120 para SQL Server 2014, CE130 para SQL Server 2016, CE140 para SQL Server 2017 y CE150 para SQL Server 2019. Comenzando con SQL Server 2017 CU10, puede usar la funcionalidad USE HINT para controlar esto con sugerencias de consulta. Por ejemplo:

/*...query...*/ OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'));

… sería una sugerencia de consulta válida para forzar el estimador de cardinalidad CE130 para una consulta en particular.

Cambios en SQL Server 2019

SQL Server 2019 está agregando aún más mejoras de rendimiento y cambios de comportamiento que están habilitados de manera predeterminada cuando una base de datos usa el modo de compatibilidad 150. Un buen ejemplo es la inserción de UDF escalar. Otro ejemplo es la función de procesamiento inteligente de consultas, que es un superconjunto del procesamiento adaptable de consultas en SQL Server 2017.

Hay cinco nuevas opciones de USE HINT, que incluyen formas de deshabilitar el modo por lotes o deshabilitar la retroalimentación de concesión de memoria adaptativa, como se muestra en la Tabla 2:

Tabla 2:Nuevas opciones de USE HINT

Y también hay dieciséis nuevas opciones de configuración en el ámbito de la base de datos (a partir de CTP 2.2) que le brindan control a nivel de la base de datos de más elementos que también se ven afectados por las marcas de seguimiento o el nivel de compatibilidad de la base de datos. Le brinda un control más detallado de los cambios de nivel superior que están habilitados de forma predeterminada con el nivel de compatibilidad de la base de datos 150. Estos se enumeran en la Tabla 3:

Tabla 3:Nuevas opciones de configuración en el ámbito de la base de datos

Conclusión

Migrar a una versión moderna de SQL Server (es decir, SQL Server 2016 o posterior) es significativamente más complicado que con las versiones heredadas de SQL Server. Debido a los cambios asociados con los diversos niveles de compatibilidad de la base de datos y las diversas versiones del estimador de cardinalidad, en realidad es muy importante pensar, planificar y probar qué nivel de compatibilidad de la base de datos desea usar en la nueva versión de SQL Server que desea. están migrando sus bases de datos existentes a.

El proceso de actualización recomendado por Microsoft es actualizar a la última versión de SQL Server, pero manteniendo el nivel de compatibilidad de la base de datos de origen. Luego, habilite Query Store en cada base de datos y recopile datos de referencia en la carga de trabajo. A continuación, establece el nivel de compatibilidad de la base de datos con la última versión y luego utiliza Query Store para corregir las regresiones de rendimiento al forzar el último plan bueno conocido.

Realmente desea evitar una migración "a ciegas" fortuita en la que no sabe cómo funciona esto y cómo reaccionará su carga de trabajo a estos cambios. Cambiar el nivel de compatibilidad de la base de datos a una versión adecuada y usar las opciones de configuración de ámbito de la base de datos adecuadas, junto con las sugerencias de consulta adecuadas cuando sea absolutamente necesario, es extremadamente importante con las versiones modernas de SQL Server.