¿Cuánto tiempo dedica a solucionar problemas de rendimiento como administrador o desarrollador de bases de datos? ¿Alguna vez lo has rastreado? Como porcentaje total promedio de su día, puede que no parezca mucho tiempo, pero cuando el problema es grave, puede pasar horas buscándolo y trabajando en el análisis de la causa raíz. A veces el problema desaparece y no sabes el verdadero origen. ¿Y aún peor? Cuando tienes que luchar contra estos problemas en medio de la noche o el fin de semana. No solo estás luchando por resolver un problema, sino que estás perdiendo tu tiempo libre personal. ¿Cómo aliviamos eso? ¿Cómo quitamos nuestro tiempo y esfuerzo de la ecuación y arreglamos el rendimiento al mismo tiempo?
La característica de ajuste automático en SQL Server 2017 Enterprise Edition y Azure SQL Database es el primer paso para reducir el tiempo que los profesionales de datos dedican a solucionar problemas de rendimiento. La característica incluye la corrección automática de planes y la administración automática de índices (solo disponible en Azure SQL Database), que se habilitan de forma independiente. En esta publicación quiero centrarme en la función de corrección automática del plan. Con la corrección automática del plan, si SQL Server descubre que una consulta ha retrocedido significativamente, forzará el último plan bueno conocido para la consulta para estabilizar el rendimiento. Esencialmente, en lugar de que usted, el DBA o el desarrollador, reciba una llamada el fin de semana sobre el rendimiento del sistema, SQL Server lo abordará por usted. Suena demasiado fácil, ¿verdad? Echemos un vistazo.
Debajo de las sábanas
En primer lugar, es fundamental comprender que la Corrección automática de planes utiliza Query Store, por lo que debe estar habilitada para la base de datos. En segundo lugar, la Corrección automática del plan es simplemente un forzado automático del plan. Si bien Query Store se comercializa como registrador de vuelo para su base de datos que rastrea el texto de la consulta, los planes, las estadísticas de tiempo de ejecución y las estadísticas de espera, también le permite forzar un plan para una consulta para permitir un rendimiento constante. La corrección automática del plan es forzar el plan sin su intervención.
Habilitar la corrección automática del plan
Como se mencionó, primero se debe habilitar Query Store para la base de datos del usuario. Esto se puede hacer en SSMS, con T-SQL y con REST API para Azure SQL DB. Tenga en cuenta que Query Store está habilitado de forma predeterminada para las bases de datos en Azure, y lo ha estado desde el cuarto trimestre de 2016.
Habilitación del almacén de consultas a través de SSMS
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Habilitación del Almacén de consultas mediante T-SQL
El código anterior es el T-SQL predeterminado de SSMS si lo escribe. En Azure SQL Database, no ejecuta la instrucción USE. Si desea cambiar alguna de las opciones predeterminadas, lea mi publicación Configuración del almacén de consultas sobre cuáles son esas opciones y las consideraciones para los valores alternativos.
Una vez que Query Store está habilitado, puede usar Azure Portal, T-SQL o EST API para habilitar la corrección automática del plan en Azure SQL Database (y C# y PowerShell están en proceso). Solo se puede habilitar con T-SQL en SQL Server 2017.
Habilitación de la corrección automática del plan en Azure Portal
ALTER DATABASE [WideWorldImporters] SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON ); GO
Habilitación de la corrección automática del plan en T-SQL
Tenga en cuenta que la Corrección automática del plan se habilitará de forma predeterminada para las nuevas bases de datos en Azure en un futuro próximo. A partir de enero de 2018, el ajuste automático se habilitará para las bases de datos SQL de Azure que aún no lo tenían habilitado, con notificaciones enviadas a los administradores para que la opción se pueda deshabilitar si lo desea.
Cómo funciona
Con la Corrección automática del plan habilitada, SQL Server supervisa el rendimiento de las consultas mediante los datos del Almacén de consultas. Busca un cambio significativo* en el rendimiento de la CPU** con una ventana de 48 horas***. Fíjate en los asteriscos en esa oración... son a propósito:
- *El umbral de lo que constituye un cambio significativo no está documentado porque Microsoft se reserva el derecho de cambiarlo.
- **La métrica utilizada para determinar el cambio en el rendimiento (CPU) no está documentada porque Microsoft se reserva el derecho de cambiarla. Es decir, Microsoft podría considerar dimensiones adicionales para observar el rendimiento si fuera mejor/rendiera mejor que solo la CPU.
- ***El período de tiempo en el que se comparan los datos de rendimiento de consultas no está documentado por la misma razón, Microsoft se reserva el derecho de cambiarlo.
- Nota:si bien los elementos antes mencionados no están documentados, confirmé con las personas correspondientes de Microsoft que esta información podría compartirse sin romper ningún NDA. Es extremadamente importante comprender que los valores no son fijos y pueden cambiar, con la expectativa de que cambien para mejorar la confiabilidad de la característica.
La falta de documentación y la posibilidad de cambios en el umbral pueden ser frustrantes para algunas personas, pero esto es lo que es realmente importante recordar:
Microsoft captura diariamente terabytes de datos de telemetría operativa de las bases de datos de SQL Azure, y esos datos son fundamentales para las funciones automáticas que se están desarrollando. Estos datos incluyen elementos como query_id, query_plan_id y query_hash, y Microsoft NO captura query_text o query_plan (no analizan sus datos reales). Microsoft no está simplemente archivando esa telemetría operativa o usándola para solucionar problemas, está extrayendo esos datos y usándolos para desarrollar algoritmos y modelos que permitan a SQL Server tomar decisiones independientes e inteligentes.
SQL Server puede aprovechar la gran cantidad de datos en Query Store que detallan el rendimiento de las consultas, y la corrección automática del plan comienza con la comparación del rendimiento actual de una consulta con el rendimiento anterior para determinar si hay una regresión en el rendimiento. ¿Ha disminuido o empeorado el rendimiento? De ser así, ¿se trata de una cantidad significativa?
Si ha habido una regresión en el rendimiento de la consulta, SQL Server forzará el último plan bueno conocido para esa consulta, que por supuesto se extrae del Almacén de consultas. Pero no se detiene allí. Luego, SQL Server continúa monitoreando el rendimiento, aún usando Query Store, para confirmar que el plan forzado sigue siendo un buen plan para esa consulta, lo que significa que la consulta con el plan forzado funciona mejor que la versión regresiva. Si esa consulta no funciona mejor, entonces cancelará el plan. Un plan también puede no ser forzado si hay una recompilación o si falla el forzado.
Este ciclo continúa; si una consulta tiene un plan forzado, y luego ese plan no es forzado por una de las razones antes mencionadas, ese mismo plan puede ser forzado nuevamente más tarde, o puede haber otro plan forzado para esa consulta en un momento posterior. Este es un proceso continuo que ocurre siempre que tenga habilitada la opción Corrección automática del plan para la base de datos. Ahora, lo interesante es que puede ver la misma información que captura esta función y usarla para forzar planes manualmente. Es decir, en SQL Server 2017 Enterprise Edition y en Azure SQL Database, estos datos se recopilan en sys.dm_db_tuning_recommendations DMV incluso cuando la función de corrección automática de planes no está habilitada, por lo que puede examinar esos datos y seguir sus recomendaciones para forzar los planes. para consultas específicas por tu cuenta. Tenga en cuenta que si fuerza un plan usando las recomendaciones de sys.dm_db_tuning_recommendations, nunca se dejará de forzar automáticamente. Además, si tiene habilitada la Corrección automática del plan y fuerza manualmente un plan, nunca se cancelará automáticamente. Solo los planes forzados con la función de Corrección automática de planes no serán forzados automáticamente.
¿Realmente voy a dejar que SQL Server tenga el control?
Si es escéptico y se pregunta si realmente puede confiar en SQL Server para tomar una decisión forzada, esto es lo que le animo a recordar:
- Esta característica se desarrolló con una asombrosa cantidad de datos capturados de casi dos millones de bases de datos Azure SQL. Es una característica nueva en SQL Server 2017, pero estuvo disponible globalmente en 2016 en Azure, por lo que esta característica realmente ha estado disponible durante más de un año y se ha perfeccionado.
- Los ingenieros han realizado cambios en el algoritmo con el tiempo, ya que han capturado más datos. Es posible que no encuentre todas las regresiones que ocurren, porque una regresión puede no ser lo suficientemente grave, pero apuesto a que muchos de ustedes preferirían tener esta función con menos frecuencia que con demasiada frecuencia.
- Además de eso, si se fuerza un plan pero termina causando un problema, la capacidad de SQL Server para recuperarse y anular el plan es extremadamente confiable y ocurre muy rápidamente.
Resumen
Es posible que no se sienta cómodo con la idea de que SQL Server aborde los problemas de rendimiento por usted. ¿Pero esa incomodidad se debe a que crees que tomará una mala decisión? ¿O le preocupa que la automatización se apodere de su trabajo? Pregunta bastante directa, lo sé. Si es lo primero, entonces mi recomendación es mirar los datos capturados en sys.dm_db_tuning_recommendations (sin habilitar la corrección automática del plan) y ver qué querría hacer SQL Server. ¿Se alinea con lo que harías? ¿Encuentra regresiones que podría pasar por alto? Si no desea habilitar la función porque tiene miedo de que de repente no tenga suficiente que hacer, lo animo a leer la publicación reciente de Conor Cunningham, Cómo la velocidad de la nube ayuda a los administradores de bases de datos de SQL Server. Microsoft no está tratando de codificarlo para que no tenga un trabajo. Simplemente están tratando de manejar la fruta madura para que puedas concentrarte en tareas más importantes.
