Aconsejabilidad de usar STATISTICS_NORECOMPUTE

Recientemente me involucré en el mantenimiento de un conjunto de bases de datos con algunos problemas de índice interesantes. Una de las que más me agrava es la diferencia en los índices entre máquinas de desarrollo, prueba, modelo y producción. Dado que las diferencias hacen que las consultas de ajuste sean bastante difíciles, sincronizarlas es uno de mis primeros proyectos.

Al comparar los entornos de prueba y modelo, me di cuenta de que la mayoría de los índices en el entorno de modelo se han STATISTICS_NORECOMPUTEconfigurado ONmientras que los de prueba no. En todos los entornos hay un trabajo nocturno que actualiza las estadísticas de todas las bases de datos.

Nunca he tratado STATISTICS_NORECOMPUTEantes, así que aquí están mis preguntas. ¿Existen mejores prácticas cuando se trata con esta configuración? Si estoy haciendo actualizaciones estadísticas al final del día, ¿es mejor activar STATISTICS_NORECOMPUTEtodos los entornos en todos los índices? ¿O hay una buena razón para no hacerlo?

EDITAR: He encontrado uno de los blogs de Kimberly Tripp sobre el tema aquí que parece sugerir que STATISTICS_NORECOMPUTEdebería usarse con moderación en el mejor de los casos. Pero todavía estoy preocupado por apagarlo globalmente. ¿Alguien ha intentado esto y qué experimentaron?

Realmente es algo situacional que desea ver por tabla o por índice, y realmente necesita averiguar qué hay en producción antes de tomar cualquier medida. En caso de duda, use también lo que se está produciendo en otros entornos, incluso si eso significa usar un montón de configuraciones locas. Simplemente no puede tener una buena idea de cómo se comportará la producción si las cosas son diferentes en la prueba o el desarrollo.

De todos modos, la recomendación general de dejar activadas las estadísticas de actualización automática ( STATISTICS_NORECOMPUTE = OFFque es la predeterminada) es por razones de seguridad, porque si esto se desactiva y nada actualiza las estadísticas manualmente, el resultado podría ser planes de ejecución realmente horrendos que nunca cambian después de que se crean por primera vez (y no se invalidan por otras razones más adelante).

Dijiste que las estadísticas de actualización automática están desactivadas para la mayoría de los índices (creo que originalmente leí mal eso como todo , no la mayoría ). Para los índices con estadísticas de actualización automática aún habilitadas, ¿tiene sentido esta configuración dada la actividad en esas tablas? Esperaría que estas sean tablas de mayor actividad. Es posible que se haya dedicado mucho trabajo a resolverlo, y puede valer la pena mantener (o considerar seriamente) esa configuración. Por lo menos, tome nota de qué estadísticas son estas, porque esa información podría ser útil en el futuro.

Pensando más en ello, diré que la estrategia actual tiene sentido. ¿Es mejor que dejar las estadísticas de actualización automática para todo? Parece que alguien pensó que sí, hasta el punto de que valía la pena la facilidad de administración de tener un trabajo de Agente SQL asociado.

Si la idea era tener estadísticas nuevas disponibles sin bloquear consultas (como esta ), podría considerar volver a activar la actualización automática para todo y luego también activarla AUTO_UPDATE_STATISTICS_ASYNC. Luego, probablemente cambie el cronograma de trabajo para que se ejecute una vez por semana en lugar de diariamente, ya que aún desea que las estadísticas se actualicen WITH FULLSCANperiódicamente.

Sin embargo, podría dejarlo, ya que probablemente tenga peces más grandes para freír si los índices en sí son diferentes entre los entornos, y las reconstrucciones de estadísticas no son demasiado dolorosas. Lo que hay ahora tiene sentido; solo necesita hacer que las cosas sean consistentes en todos los entornos. Probablemente sea marginalmente mejor que las configuraciones más simples que sugerí, a expensas de que se haga más trabajo. Pero descubra qué hay en producción, procure usar eso y pase a cosas más importantes; revise esto cuando esté a punto de necesitar ajustar el rendimiento con mayor precisión: las mejores estadísticas del mundo no guardarán una consulta a la que le falta un índice crítico.