Qué es Query Store en SQL Server

Para empezar, una de mis features favoritas de los últimos tiempos. Nace con una mira hacia facilitar el monitoreo y el troubleshooting de nuestras consultas y ha evolucionado en grandes mejoras entre las últimas versiones. Veamos en esta oportunidad qué es Query Store en SQL Server.

Solo como dato

Query Store se inicia en SQL Server 2016 on-premise. Su uso en Azure ha sido determinante desde el año 2015 para muchas mejoras en el motor. Almacena automáticamente las consultas, planes de ejecución y estadísticas de runtime para un análisis. Una gran facilidad que nos da es el permitirnos ver si un plan de ejecución ha cambiado en el tiempo.

¿Cómo lo activo?

En Azure viene activo por defecto. En tu servidor on-premise basta con darle un click derecho y propiedades en la base de datos donde quieres activarlo y seleccionar una de estas opciones como se ve en la imagen.

Inmediatamente puedes ver que en tu base de datos se han adicionado componentes en el explorador de objetos.

¿Qué datos obtengo con esto?

Como puedes ver en las mismas opciones, ya tienes activada la opción de captura de información de tus consultas que te permita ver datos estadísticos para identificar las más pesadas, aquellas con cambios de comportamiento, aquellas con más uso de recursos y otra información relevante.

Para tener una idea general, quiero que veas en esta imagen algunos puntos interesantes del reporte «Top Resource Consuming Queries«.

En esta pantalla dividida vemos en la sección izquierda una gráfica con la historia de consultas con mayor tiempo de ejecución, donde si mantienes el cursor sobre alguna de las barras verticales, verás su duración en milisegundos o la cantidad de veces que se ha ejecutado. En la sección derecha verás los cambios que ha tenido su plan ejecución en el tiempo. Y finalmente en la parte inferior verás el plan de ejecución que corresponde a la consulta señalada.

Query Store en SQL Server muesta cambios en planes de ejecución

Una de las opciones que más me gusta sin duda. Y claro, uno de los principales objetivos de esta feature.

(Seguro que ya viste qué es el Plan Cache en SQL Server y pues es importante que conozcas los conceptos generales de un plan de ejecución).

El plan de ejecución de una consulta puede cambiar de acuerdo con los diferentes escenarios en los que ella se ejecuta. Aquí consideramos variaciones en las estadísticas de los datos o cambios de estructuras como índices.

Así es. El plan de ejecución de una consulta puede cambiar en el tiempo. Dependiendo del análisis este cambio puede ser bueno o malo.

¿Cómo nos ayuda Query Store en SQL Server para ver estos cambios?

Fíjate bien en esta imagen. Al señalar una barra vertical de la sección izquierda, podemos ver dos círculos en la sección derecha,

Puedes ver que el Plan Id se encuentra señalado con el valor 36. En la sección inferior observa que la consulta es realizada a través de un Clustered Index Scan.

Observa que más tarde, en la línea de tiempo, se ha generado otro plan de ejecución para la consulta. Si señalamos el otro círculo con Plan Id 39 mira qué pasó.

Ahora señalado el círculo más actual puedes observar que en la sección inferior se ve un plan totalmente diferente. La misma consulta realizó un NonClustered Index Seek con un Key Lookup. Además puedes ver que el esfuerzo fue menor.

¿Puede el mismo Query comportarse de diferentes maneras?

Claro que sí, por eso es importante tomar estas precauciones y ahora puedes apoyarte con Query Store.

También puedes revisar la publicación Desarrollo vs Producción que nos habla de los resultados diferentes entre ambientes para tener algunas consideraciones adicionales.

Algunas consideraciones adicionales en el uso de Query Store en SQL Server

Tenemos muchas opciones en la utilización de Query Store y las veremos en nuestros webinars periódicos. No te pierdas las invitaciones suscribiéndote en este enlace.

Es una buena alternativa utilizar siempre la versión más reciente de SQL Server Management Studio para esta feature.

No hay una configuración por defecto o estándar. Debes evaluar tu flujo de trabajo para generar tu propia línea base.