Cambio del nivel de compatibilidad de la base de datos y uso del Almacén de consultas

  • Artículo

Se aplica a:SQL Server: solo Windows

En SQL Server 2016 (13.x) y versiones posteriores, algunos cambios solo se habilitan una vez que se ha cambiado el nivel de compatibilidad de la base de datos. Esto se realiza por varias razones:

  • Ya que la actualización es una operación unidireccional (no se puede degradar el formato de archivo), hay un valor en la separación de la habilitación de características nuevas para una operación independiente dentro de la base de datos. Es posible revertir un valor a un nivel de compatibilidad de la base de datos anterior. El nuevo modelo reduce el número de pasos que hay que realizar durante una ventana de interrupción.

  • Los cambios en el procesador de consultas pueden tener efectos complejos. Aunque un cambio "bueno" en el sistema puede ser positivo para la mayoría de las cargas de trabajo, para otras podría causar una regresión inaceptable en una consulta importante. Separar esta lógica del proceso de actualización permite que las características, como el Almacén de consultas, mitiguen las regresiones de elección del plan rápidamente o incluso las eviten completamente en servidores de producción.

Se prevén los siguientes comportamientos para SQL Server 2017 (14.x) cuando se adjunta o se restaura una base de datos, así como después de una actualización local:

  • Si el nivel de compatibilidad de una base de datos de usuario era 100 o superior antes de la actualización, permanece igual después de la misma.
  • Si el nivel de compatibilidad de una base de datos de usuario era 90 antes de la actualización, en la base de datos actualizada el nivel de compatibilidad se establece en 100, que es el nivel de compatibilidad mínimo admitido en SQL Server 2017 (14.x).
  • Los niveles de compatibilidad de las bases de datos tempdb, model, msdb y Resource quedan establecidos en el nivel de compatibilidad actual después de la actualización.
  • La base de datos del sistema master conserva el nivel de compatibilidad que tenía antes de la actualización.

El proceso de actualización para habilitar la nueva funcionalidad del procesador de consultas está relacionado con el modelo de servicio posterior a la versión del producto. Algunas de esas correcciones se publican bajo la Marca de seguimiento 4199. Los clientes que necesitan correcciones pueden participar en esas correcciones sin causar regresiones inesperadas para otros clientes. El modelo de mantenimiento posterior a la versión para las revisiones del procesador de consultas se documenta aquí. A partir de SQL Server 2016 (13.x), moverse a un nuevo nivel de compatibilidad implica que ya no se necesita la Marca de seguimiento 4199, puesto que esas correcciones ya están habilitadas de forma predeterminada en el nivel de compatibilidad más reciente. Por lo tanto, como parte del proceso de actualización, es importante validar que 4199 no está habilitado una vez que se completa el proceso de actualización.

Nota:

La Marca de seguimiento 4199 sigue resultando necesaria para habilitar cualquier nueva corrección del procesador de consultas publicada después de RTM, si procede.

El flujo de trabajo recomendado para actualizar el procesador de consultas a la versión más reciente del código está documentado en la sección Mantener la estabilidad del rendimiento al actualizar a una versión más reciente de SQL Server de Escenarios de uso del Almacén de consultas, tal y como se muestra abajo.

Diagrama que muestra el flujo de trabajo recomendado para actualizar el procesador de consultas a la versión más reciente del código.

A partir de la versión 18 de SQL Server Management Studio, se guía a los usuarios por el flujo de trabajo recomendado mediante el Asistente para la optimización de consultas. Para obtener más información, vea Actualizar bases de datos mediante el Asistente para la optimización de consultas.

Consulte también