Cuando crea una nueva base de datos en SQL Server, la opción Actualización automática de estadísticas está habilitada de manera predeterminada. Generalmente se recomienda dejar esta opción habilitada. Idealmente, las estadísticas son administradas por un trabajo programado, y la opción automática se usa como una red de seguridad, disponible para actualizar las estadísticas en caso de que no ocurra una actualización programada, o si accidentalmente no incluye todas las estadísticas existentes.
Algunos administradores de base de datos se basan únicamente en actualizaciones automáticas para administrar las estadísticas y, siempre que no existan problemas de rendimiento relacionados con estadísticas desactualizadas o mal muestreadas, esto es aceptable. Si confía en esta opción para administrar sus estadísticas y tiene algunas tablas muy grandes, podría valer la pena implementar el indicador de seguimiento 2371. Al igual que con cualquier indicador de seguimiento, asegúrese de probar con una carga de trabajo representativa antes de implementarlo en producción. Es posible que ya sepa que hay momentos en que una actualización automática puede afectar el rendimiento del sistema. Por ejemplo, la actualización de una estadística puede introducir un pico en la CPU o la E/S a medida que se leen los datos de la tabla o el índice, así como retrasar la ejecución de la consulta mientras se produce la actualización. Hay otra opción de base de datos que puede habilitar para abordar ese retraso de consulta, y lo cubriré más adelante en esta publicación.
La pregunta que me hacen a menudo es:"¿Cómo saber si las actualizaciones automáticas de las estadísticas causan problemas de rendimiento?" Una opción es realizar un seguimiento de ellos y vincular las actualizaciones a un cambio en el rendimiento. Existen muchas opciones para realizar un seguimiento de las actualizaciones, y en esta publicación revisaremos algunos de los métodos disponibles para que pueda elegir y luego implementar el opción que mejor se adapte a su método actual de supervisión de problemas de rendimiento.
Rastreo SQL
Si está ejecutando SQL Server 2008 R2 o anterior en su entorno, SQL Trace es un método que puede usar para capturar actualizaciones automáticas. El script de definición de seguimiento que se usa a continuación solo captura el evento Auto Stats, que detecta cuándo una estadística se actualiza automáticamente y cuándo una estadística se crea automáticamente. Después de que este seguimiento se haya ejecutado durante un tiempo en su entorno, puede cargarlo en una tabla y luego consultar el resultado para ver qué actualizaciones se produjeron. La secuencia de comandos incluida a continuación muestra un ejemplo utilizando la base de datos de muestra de estadísticas de béisbol.
Eventos extendidos
Si está ejecutando SQL Server 2012 o superior, le recomiendo usar eventos extendidos para capturar actualizaciones automáticas. Al igual que la secuencia de comandos SQL Trace, la secuencia de comandos de definición de sesión incluida solo captura los eventos de Auto Stats; nuevamente, tanto las actualizaciones automáticas como las creaciones automáticas. Una vez que la sesión XE se haya ejecutado durante un tiempo, puede cargar el resultado en una tabla a través de la interfaz de usuario y luego consultarlo para ver qué actualizaciones se produjeron. El script incluido recorre el mismo ejemplo que antes, pero esta vez usando eventos extendidos para recopilar los datos.
sys.dm_db_stats_properties
Una tercera opción que podría considerar para monitorear las actualizaciones de estadísticas es sys.dm_db_stats_properties DMF, que solo está disponible en SQL Server 2008 R2 SP2 y superior, y SQL Server 2012 SP1 y superior. Por mucho que me encante este DMF, esta solución es más complicada en términos de asegurarse de capturar todos los datos, y revisar la salida requiere más trabajo. Con el DMF, no se realiza un seguimiento de todas las actualizaciones automáticas, solo actualizamos las estadísticas de tendencias para ver cuándo se producen las actualizaciones.
Es una tarea simple:crea una tabla para contener la información de estadísticas y luego toma instantáneas de la información del DMF en la tabla de forma regular. La clave aquí es averiguar con qué frecuencia capturar los datos. Cada hora es probablemente una exageración, una vez al día puede no ser lo suficientemente frecuente. Recomiendo comenzar con un trabajo del Agente SQL que tome instantáneas de los datos DMF cada cuatro horas. Deje que se ejecute durante unos días, luego verifique sus datos. Si las estadísticas se actualizan una vez al día como máximo, puede aumentar el intervalo a cada ocho o doce horas. Si las estadísticas se actualizan fácilmente cada cuatro horas, reduzca su intervalo a cada dos horas:debe asegurarse de capturar cada actualización. Por esta razón, para algunos sistemas, sys.dm_db_stats_properties puede que no valga la pena el esfuerzo; una sesión XE o Trace podría ser más simple.
Una secuencia de comandos de muestra final muestra un ejemplo de cómo usaría sys.dm_db_stats_properties para actualizar las tendencias de las estadísticas. Tenga en cuenta que este script solo captura información estadística para una tabla. Si modifica la secuencia de comandos para capturar todas las tablas de la base de datos, habrá muchos más datos para analizar.
Siguientes pasos
Descargue los scripts de muestra y decida qué método debe usar para realizar un seguimiento de las actualizaciones de estadísticas.
Una vez que tenga los datos que muestran cuándo ocurren las actualizaciones automáticas, debe relacionarlos con los problemas de rendimiento conocidos. Como tal, si no está rastreando ninguna métrica de rendimiento, entonces los datos de actualización de estadísticas automáticas no ayudarán con ningún tipo de correlación. Suponiendo que tiene marcas de tiempo para cualquier problema de rendimiento, puede compararlo con el StartTime y EndTime de Trace, la timestamp desde XE, o last_updated de sys.dm_db_stats_properties DMF, para determinar si la actualización automática afectó el rendimiento del sistema.
Si no puede establecer ninguna correlación entre las actualizaciones y los problemas de rendimiento, puede descartar las actualizaciones como la causa del problema y centrarse en otra área. Si las actualizaciones son la causa raíz, entonces tiene dos opciones:deshabilitar la opción Actualización automática de estadísticas o habilitar la opción Actualización automática de estadísticas de forma asíncrona. Ambos tienen pros y contras que usted, como DBA, debe considerar.
Deshabilitar las estadísticas de actualización automática
Si elige deshabilitar la opción de actualización automática de estadísticas, las dos cosas más importantes que debe saber son:
- Es absolutamente necesario administrar sus estadísticas a través de una tarea de mantenimiento o un trabajo personalizado.
- Las consultas no se volverán a compilar cuando actualice las estadísticas en SQL Server 2008 R2 y versiones anteriores.
Veo el segundo elemento como un desafío mayor:soy un gran defensor de la gestión de estadísticas y espero que sea algo que los DBA estén haciendo de todos modos. El problema más grande es que, aunque la actualización de las estadísticas normalmente hace que las consultas se vuelvan a compilar (para aprovechar las estadísticas actualizadas), esto no ocurrir cuando tiene deshabilitada la opción de actualización automática de estadísticas. He escrito sobre esto anteriormente y recomiendo revisar esta información si no está familiarizado con este comportamiento. También vea una publicación de seguimiento para conocer las opciones para abordarlo.
En general, este no es el camino que recomiendo. Hay casos extremos muy específicos en los que esto podría ser apropiado, pero preferiría ver a un DBA realizar actualizaciones manuales (a través de trabajos programados) para evitar las actualizaciones automáticas y dejar la opción habilitada como medida de seguridad.
Habilitar las estadísticas de actualización automática de forma asíncrona
Cuando habilita la opción Actualización automática de estadísticas de forma asíncrona, si una estadística ha sido invalidada y se ejecuta una consulta que usa esa estadística, la estadística no se actualizará hasta que la consulta se haya completado; la actualización es asíncrona. El beneficio aquí es que la actualización no afectará la consulta que se ejecutó; el inconveniente es que la consulta utilizará el plan existente, que puede que ya no sea el plan óptimo. Si el plan sigue siendo óptimo dependerá de su carga de trabajo (por ejemplo, una carga de trabajo de informes con consultas de ejecución prolongada). Como DBA, debe sopesar los pros y los contras de habilitar esta opción y determinar qué es lo mejor para su base de datos. Tenga en cuenta que si está ejecutando SQL Server 2008 a 2012, hay una pérdida de memoria asociada con esta configuración. Microsoft tiene actualizaciones acumulativas disponibles que brindan una solución, pero si aún no las tiene aplicadas, se enfrenta a otra decisión:aplique la CU para poder habilitar la opción, o no aplique la CU y no habilite la opción.
Resumen
La única forma de saber si las actualizaciones automáticas de las estadísticas están afectando el rendimiento de las consultas es ver que se produce una actualización al mismo tiempo que un problema o capturar cuándo se producen las actualizaciones y correlacionar los datos con la información adicional que está capturando sobre los problemas de rendimiento. La última opción le permite ser proactivo, incluso si no tiene problemas de rendimiento, puede ser una buena idea saber con qué frecuencia ocurren las actualizaciones automáticas. Las actualizaciones frecuentes pueden significar que debe volver a visitar el trabajo del Agente que administra manualmente las estadísticas. En general, deje habilitada la opción para actualizar automáticamente las estadísticas, pero tenga un método para administrar las estadísticas y use la opción como una red de seguridad.
