Comprender las estadísticas, los planes de ejecución y el "problema clave ascendente"

Estoy tratando de comprender mejor (conceptualmente) la relación entre estadísticas, planes de ejecución, ejecución de procedimientos almacenados.

¿Estoy en lo cierto al decir que las estadísticas solo se usan cuando se crea el plan de ejecución para un procedimiento almacenado y no se usan en el contexto de ejecución real? En otras palabras, si esto es cierto, una vez que se crea el plan (y suponiendo que se reutilice correctamente), ¿qué importancia tienen las estadísticas "actualizadas"?

Estaba particularmente motivado por un artículo que leí ( Estadísticas, estimaciones de filas y la columna de fecha ascendente ) que describe un escenario muy similar al que enfrento diariamente con varias de las bases de datos de nuestros clientes.

Tenemos una columna de fecha / hora ascendente en una de nuestras tablas más grandes que consultamos regularmente utilizando un procedimiento almacenado específico.

¿Cómo evita que los planes de ejecución se vuelvan obsoletos cuando se agregan cien mil filas al día?

Si estamos actualizando estadísticas con frecuencia para combatir este problema, ¿tendría sentido usar la sugerencia OPTION (RECOMPILE) en la consulta de este procedimiento almacenado?

Cualquier consejo o recomendación sería apreciado.

Actualización : estoy usando SQL Server 2012 (SP1).

¿Estoy en lo cierto al decir que las estadísticas solo se usan cuando se crea el plan de ejecución para un procedimiento almacenado y no se usan en el contexto de ejecución real?

No, lo que sucede es que el plan de ejecución para un procedimiento almacenado se almacena en caché. Suponiendo que haya suficiente memoria disponible para continuar manteniendo el plan, no cambiará a menos que ocurra una de las siguientes situaciones (de Caché y reutilización del plan de ejecución en la documentación de SQL Server, énfasis agregado):

• Cambios realizados en una tabla o vista referenciada por la consulta (ALTER TABLE y ALTER VIEW).
• Los cambios realizados en un solo procedimiento, que eliminarían todos los planes para ese procedimiento del caché (ALTER PROCEDURE).
• Cambios en los índices utilizados por el plan de ejecución.
• Actualizaciones sobre estadísticas utilizadas por el plan de ejecución, generadas explícitamente a partir de una declaración, como ACTUALIZAR ESTADÍSTICAS, o generadas automáticamente.
• Descartar un índice utilizado por el plan de ejecución.
• Una llamada explícita a sp_recompile.
• Gran cantidad de cambios en las claves (generados por las instrucciones INSERT o DELETE de otros usuarios que modifican una tabla a la que hace referencia la consulta).
• Para tablas con disparadores, si el número de filas en las tablas insertadas o eliminadas aumenta significativamente.
• Ejecutar un procedimiento almacenado usando la opción WITH RECOMPILE.

Entonces, si las estadísticas se actualizan, el plan en caché tomará automáticamente en cuenta las nuevas estadísticas y se volverá a compilar.

¿Cómo evita que los planes de ejecución se vuelvan obsoletos cuando se agregan cien mil filas al día?

Una forma es si hay muchas actualizaciones en la tabla, como se mencionó anteriormente. Unos cientos de miles de filas modificadas pueden satisfacer esta condición. Pero si quieres estar seguro o tener un control más granular: actualizando tus estadísticas. Puede permitir que SQL Server cree y administre automáticamente estadísticas, o hacerlo manualmente usted mismo. Puede encontrar más información sobre cualquiera de los métodos en SQL Server Auto Update y Auto Create Statistics Options . Cuando / si realiza una reconstrucción semanal de índices, esto también activará la actualización de los planes. Haga algunas pruebas para ver qué es lo más beneficioso para usted, ya que actualizar las estadísticas con demasiada frecuencia puede no arrojar ningún resultado de rendimiento real.

Si estamos actualizando estadísticas con frecuencia para combatir este problema, ¿tendría sentido usar la sugerencia OPTION (RECOMPILE) en la consulta de este procedimiento almacenado?

No necesita usarlo RECOMPILE, ya que según el extracto anterior, puede ver que el plan de ejecución se actualiza adecuadamente cada vez que hay nuevas estadísticas disponibles. Puede estar bien con una actualización de estadísticas al final del día (si está realmente preocupado), pero no creo que sea explícitamente una necesidad basada en lo que ha dicho hasta ahora. Una vez más, sin embargo, lo probaría para ver qué impacto puede tener esto en el rendimiento de su procedimiento almacenado y planificar en consecuencia.

¿Estoy en lo cierto al decir que las estadísticas solo se usan al crear el plan de ejecución

No, las estadísticas desactualizadas pueden causar una compilación relacionada con la optimización de la declaración afectada.

Tenemos una columna de fecha / hora ascendente en una de nuestras tablas más grandes que consultamos regularmente

Los planes de ejecución subóptimos causados ​​por valores predicados que están fuera (específicamente arriba) del rango de valores almacenados en el histograma estadístico correspondiente se conocen como el Problema clave ascendente . Reconstruir estadísticas es una solución posible, pero puede requerir muchos recursos. Las alternativas incluyen:

• Traza las banderas 2389 y 2390 . Esto requiere que exista un índice con la columna problemática como clave principal. No funciona con tablas particionadas, y solo es efectivo en SQL Server 2014 si se usa el estimador de cardinalidad original. La marca de seguimiento 4139 también puede ser necesaria si el objeto de estadísticas está marcado como estacionario.

• Actualice a SQL Server 2014. El nuevo estimador de cardinalidad incluye lógica para estimar más allá del histograma utilizando información de densidad promedio. Esto puede ser menos preciso que los indicadores de seguimiento 2389/2390 en algunas circunstancias importantes.

• Habilite actualizaciones de estadísticas automáticas más frecuentes para tablas grandes con la marca de seguimiento 2371 . Con este indicador de seguimiento, en lugar de actualizar después de 20% + 500 cambios, soloSQRT(1000 * Table rows) se requieren modificaciones . Esta no es una solución tan completa como las mencionadas anteriormente, ya que es posible que las actualizaciones aún no se activen con la frecuencia suficiente.

Si la fuente de su problema no son tanto las compilaciones de planes frecuentes basadas en valores de predicado más allá del histograma, sino más acerca de los efectos de almacenar ocasionalmente en caché un plan tan malo como resultado de la detección de parámetros, también podría considerar:

• Deshabilitar la detección de parámetros con la marca de seguimiento 4136
• Utilizando OPTIMIZE FOR (@parameter = value)para compilar un plan para un valor representativo conocido
• Usando OPTIMIZE FOR (@parameter UNKNOWN)para optimizar usando la distribución promedio
• Usando OPTIMIZE FOR UNKNOWN(igual que 4136, pero por consulta)
• Utilizando OPTION (RECOMPILE)para compilar cada vez, olfateando el valor particular. Si la gran mayoría de los valores de tiempo de ejecución están dentro del histograma, esto puede ser efectivo.

Para obtener más información sobre la detección de parámetros, la integración y las opciones de recompilación, consulte mi artículo en SQLperformance.com.