Benjamin Nevarez es un consultor independiente con sede en Los Ángeles, California, que se especializa en el ajuste y la optimización de consultas de SQL Server. Es autor de "SQL Server 2014 Query Tuning &Optimization" y "Inside the SQL Server Query Optimizer" y coautor de "SQL Server 2012 Internals". Con más de 20 años de experiencia en bases de datos relacionales, Benjamin también ha sido ponente en muchas conferencias de SQL Server, incluidas PASS Summit, SQL Server Connections y SQLBits. El blog de Benjamin se puede encontrar en http://www.benjaminnevarez.com y también se le puede contactar por correo electrónico en admin en benjaminnevarez punto com y en twitter en @BenjaminNevarez.
¿Alguna vez encontró una regresión del plan después de una actualización de SQL Server y quiso saber cuál era el plan de ejecución anterior? ¿Alguna vez ha tenido un problema de rendimiento de consultas debido al hecho de que una consulta obtuvo inesperadamente un nuevo plan de ejecución? En la última PASS Summit, Conor Cunningham descubrió una nueva característica de SQL Server, que puede ser útil para resolver problemas de rendimiento relacionados con estos y otros cambios en los planes de ejecución.
Esta función, denominada Almacén de consultas, puede ayudarlo con los problemas de rendimiento relacionados con los cambios de plan y estará disponible pronto en SQL Azure y más adelante en la próxima versión de SQL Server. Aunque se espera que esté disponible en Enterprise Edition de SQL Server, aún no se sabe si estará disponible en Standard o en otras ediciones. Para comprender los beneficios del Almacén de consultas, permítanme hablar brevemente sobre el proceso de solución de problemas de consultas.
¿Por qué una consulta es lenta?
Una vez que haya detectado que un problema de rendimiento se debe a que una consulta es lenta, el siguiente paso es averiguar por qué. Obviamente, no todos los problemas están relacionados con los cambios de planes. Puede haber múltiples razones por las que una consulta que ha funcionado bien se vuelve repentinamente lenta. A veces, esto podría estar relacionado con un bloqueo o un problema con otros recursos del sistema. Algo más puede haber cambiado, pero el desafío puede ser averiguar qué. Muchas veces no tenemos una línea de base sobre el uso de recursos del sistema, las estadísticas de ejecución de consultas o el historial de rendimiento. Y por lo general no tenemos idea de cuál era el plan anterior. Puede darse el caso de que algún cambio, por ejemplo, datos, esquema o parámetros de consulta, haga que el procesador de consultas produzca un nuevo plan.
Cambios de plan
En la sesión, Conor usó la herramienta Picasso Database Query Optimizer Visualizer, aunque no la mencionó por su nombre, para mostrar por qué cambiaron los planes en la misma consulta y explicó el hecho de que se podían seleccionar diferentes planes para la misma consulta en función de la selectividad de sus predicados. Incluso mencionó que el equipo del optimizador de consultas utiliza esta herramienta, que fue desarrollada por el Instituto Indio de Ciencias. Un ejemplo de la visualización (haga clic para ampliar):
Picasso Database Query Optimizer Visualizer
Cada color del diagrama es un plan diferente y cada plan se selecciona en función de la selectividad de los predicados. Un dato importante es que cuando se cruza un límite en el gráfico y se selecciona un plan diferente, la mayoría de las veces el costo y el rendimiento de ambos planes deben ser similares, ya que la selectividad o el número estimado de filas solo cambia ligeramente. Esto podría suceder, por ejemplo, cuando se agrega una nueva fila a una tabla que califica para el predicado usado. Sin embargo, en algunos casos, principalmente debido a limitaciones en el modelo de costos del optimizador de consultas en el que no es capaz de modelar algo correctamente, el nuevo plan puede tener una gran diferencia de rendimiento en comparación con el anterior, creando un problema para su aplicación. Por cierto, los planes que se muestran en el diagrama son el plan final seleccionado por el optimizador de consultas, no confunda esto con las muchas alternativas que el optimizador debe considerar para seleccionar solo uno.
Un hecho importante, en mi opinión, que Conor no cubrió directamente, fue el cambio de planes debido a regresiones después de cambios en actualizaciones acumulativas (CU), service packs o actualizaciones de versión. Una preocupación importante que viene a la mente con los cambios dentro del optimizador de consultas son las regresiones del plan. El miedo a las regresiones del plan se ha considerado el mayor obstáculo para las mejoras del optimizador de consultas. Las regresiones son problemas que se presentan después de que se ha aplicado una solución al optimizador de consultas y, en ocasiones, se denominan los clásicos "dos o más errores hacen un acierto". Esto puede ocurrir cuando, por ejemplo, dos malas estimaciones, una sobreestimando un valor y la otra subestimando, se anulan entre sí, dando afortunadamente una buena estimación. Corregir solo uno de estos valores ahora puede conducir a una mala estimación que puede afectar negativamente la elección del plan y provocar una regresión.
¿Qué hace el almacén de consultas?
Conor mencionó que Query Store funciona y puede ayudar con lo siguiente:
- Almacenar el historial de planes de consulta en el sistema;
- Capturar el rendimiento de cada plan de consulta a lo largo del tiempo;
- Identifique las consultas que "se han vuelto más lentas recientemente";
- Le permite forzar planes rápidamente; y,
- Asegúrese de que esto funcione en los reinicios del servidor, actualizaciones y recompilaciones de consultas.
Por lo tanto, esta función no solo almacena los planes y la información relacionada con el rendimiento de las consultas, sino que también puede ayudarlo a forzar fácilmente un plan de consultas anterior, lo que en muchos casos puede resolver un problema de rendimiento.
Cómo utilizar el almacén de consultas
Debe habilitar el Almacén de consultas mediante ALTER DATABASE CURRENT SET QUERY_STORE = ON; declaración. Lo probé en mi suscripción actual de SQL Azure, pero la declaración devolvió un error ya que parece que la función aún no está disponible. Me comuniqué con Conor y me dijo que la función estará disponible pronto.
Una vez que el Almacén de consultas esté habilitado, comenzará a recopilar los planes y los datos de rendimiento de las consultas y podrá analizar esos datos consultando las tablas del Almacén de consultas. Actualmente puedo ver esas tablas en SQL Azure pero, como no pude habilitar Query Store, los catálogos no devolvieron datos.
Puede analizar la información recopilada de manera proactiva para comprender los cambios en el rendimiento de las consultas en su aplicación o retroactivamente en caso de que tenga un problema de rendimiento. Una vez que identifique el problema, puede usar las técnicas tradicionales de ajuste de consultas para tratar de solucionar el problema, o puede usar el sp_query_store_force_plan procedimiento almacenado para forzar un plan anterior. El plan debe capturarse en Query Store para ser forzado, lo que obviamente significa que es un plan válido (al menos cuando se recopiló; más sobre eso más adelante) y fue generado por el optimizador de consultas antes. Para forzar un plan necesitas el plan_id , disponible en el sys.query_store_plan catalogar. Una vez que observa las diferentes métricas almacenadas, que son muy similares a las que se almacenan, por ejemplo, en sys.dm_exec_query_stats , puede tomar la decisión de optimizar para una métrica específica, como CPU, E/S, etc. Luego, simplemente puede usar una declaración como esta:
EXEC sys.sp_query_store_force_plan @query_id = 1, @plan_id = 1;
Esto le dice a SQL Server que fuerce el plan 1 en la consulta 1. Técnicamente, podría hacer lo mismo usando una guía de plan, pero sería más complicado y tendría que recopilar manualmente y encontrar el plan requerido en primer lugar.
¿Cómo funciona el almacén de consultas?
En realidad, forzar un plan utiliza guías de plan en segundo plano. Conor mencionó que "cuando compila una consulta, agregamos implícitamente una sugerencia de USE PLAN con el fragmento del plan XML asociado con esa declaración". Por lo tanto, ya no necesita usar una guía de planes. También tenga en cuenta que, al igual que usar una guía de planes, no se garantiza tener exactamente el plan forzado, pero al menos algo similar. Para recordar cómo funcionan las guías de planes, consulte este artículo. Además, debe tener en cuenta que hay algunos casos en los que forzar un plan no funciona, un ejemplo típico es cuando el esquema ha cambiado, es decir, si un plan almacenado usa un índice pero el índice ya no existe. En este caso, SQL Server no puede forzar el plan, realizará una optimización normal y registrará el hecho de que la operación de forzar el plan falló en el sys.query_store_plan catálogo.
Arquitectura
Cada vez que SQL Server compila o ejecuta una consulta, se envía un mensaje al Almacén de consultas. Esto se muestra a continuación.
Descripción general del flujo de trabajo del almacén de consultas
La información de compilación y ejecución se guarda primero en la memoria y luego se guarda en el disco, según la configuración del Almacén de consultas (los datos se agregan según el INTERVAL_LENGTH_MINUTES parámetro, que por defecto es de una hora, y vaciado al disco de acuerdo con el DATA_FLUSH_INTERVAL_SECONDS parámetro). Los datos también se pueden vaciar en el disco si hay presión de memoria en el sistema. En cualquier caso, podrá acceder a todos los datos, tanto en la memoria como en el disco, cuando ejecute sys.query_store_runtime_stats catálogo.
Catálogos
Los datos recopilados se conservan en el disco y se almacenan en la base de datos del usuario donde está habilitado Query Store (y la configuración se almacena en sys.database_query_store_options . Los catálogos de Query Store son:
sys.query_store_query_text | Información de texto de consulta |
sys.query_store_query | Texto de consulta más el plan usado que afecta las opciones SET |
sys.query_store_plan | Planes de ejecución, incluido el historial |
sys.query_store_runtime_stats | Estadísticas de tiempo de ejecución de consultas |
sys.query_store_runtime_stats_interval | Hora de inicio y fin de los intervalos |
sys.query_context_settings | Información de configuración de contexto de consulta |
Consultar vistas del almacén
Las estadísticas de tiempo de ejecución capturan una gran cantidad de métricas, incluido el promedio, el último, el mínimo, el máximo y la desviación estándar. Aquí está el conjunto completo de columnas para sys.query_store_runtime_stats :
runtime_stats_id | plan_id | runtime_stats_interval_id | ||
execution_type | execution_type_desc | first_execution_time | last_execution_time | count_executions |
avg_duration | last_duration | min_duration | max_duration | stdev_duration |
avg_cpu_time | last_cpu_time | min_cpu_time | max_cpu_time | stdev_cpu_time |
avg_logical_io_reads | last_logical_io_reads | min_logical_io_reads | max_logical_io_reads | stdev_logical_io_reads |
avg_logical_io_writes | last_logical_io_writes | min_logical_io_writes | max_logical_io_writes | stdev_logical_io_writes |
avg_physical_io_reads | last_physical_io_reads | min_physical_io_reads | max_physical_io_reads | stdev_physical_io_reads |
avg_clr_time | last_clr_time | min_clr_time | max_clr_time | stdev_clr_time |
avg_dop | last_dop | min_dop | max_dop | stdev_dop |
avg_query_max_used_memory | last_query_max_used_memory | min_query_max_used_memory | max_query_max_used_memory | stdev_query_max_used_memory |
avg_rowcount | last_rowcount | min_rowcount | max_rowcount | stdev_rowcount |
Columnas en sys.query_store_runtime_stats
Estos datos solo se capturan cuando finaliza la ejecución de la consulta. El Query Store también considera el SET de la consulta opciones, que pueden afectar la elección de un plan de ejecución, ya que afectan cosas como los resultados de evaluar expresiones constantes durante el proceso de optimización. Cubro este tema en una publicación anterior.
Conclusión
Esta será definitivamente una gran característica y algo que me gustaría probar lo antes posible (por cierto, la demostración de Conor muestra "SQL Server 15 CTP1", pero esos bits no están disponibles públicamente). El Almacén de consultas puede ser útil para actualizaciones que podrían ser una CU, un paquete de servicio o una versión de SQL Server, ya que puede analizar la información recopilada por el Almacén de consultas antes y después para ver si alguna consulta ha retrocedido. (Y si la función está disponible en ediciones anteriores, incluso podría hacer esto en un escenario de actualización de SKU). Saber esto puede ayudarlo a tomar alguna acción específica según el problema, y una de esas soluciones podría ser forzar el plan anterior. como se explicó antes.
