Rendimiento del servidor SQL degradación repentina

Tengo un SQL Server 2005 que se ha vuelto impredecible últimamente, y me estoy rascando la cabeza por qué. Las consultas que se ejecutan en segundos cambian los planes y toman minutos (tomar el tiempo en el análisis completo de la tabla o en el spool de índice). Ahora, lo primero y más obvio es que las estadísticas son obsoletas, lo que hace que el optimizador se confunda, pero estoy convencido de que este no es el caso, en primer lugar porque los datos subyacentes no cambian significativamente (por ejemplo, agregar los datos de un día sobre los datos de un año ya en una tabla) y en segundo lugar porque las estadísticas de creación automática y las estadísticas de actualización automática son verdaderas. Sin embargo, el optimizador se está confundiendo; ejecutar el SQL en el Asesor de ajuste me da muchas CREATE STATISTICSdeclaraciones de varias columnas que parecen solucionarlo (hasta el siguiente bit de comportamiento incorrecto de SQL).

¿Alguna idea de una estrategia que pueda usar para abordar esta causa raíz? ¿Por qué las estadísticas "normales" no son suficientes?

Si su espera superior es SOS_SCHEDULER_YIELD, parecería que tiene algo de presión sobre la CPU. Pero esto podría ser el resultado de algo más, como que su diseño ya no sea suficiente para sus consultas. Sé que dijiste que solo estás agregando datos para un día, pero podrías haber llegado a un punto de inflexión.

¿Cómo se emiten sus consultas? ¿Es SQL dinámico? ¿Estás utilizando procedimientos almacenados? ¿Estás usando sp_executesql? ¿Es posible que tenga un caso de detección de parámetros? ¿Cómo es tu diseño de db? ¿Cuáles son las relaciones PK y FK?

¿Tienes un ejemplo de un buen plan? Si puede determinar un buen plan, puede usar guías de plan para forzar la ejecución de la consulta de una manera específica.

¿Puedes dar un ejemplo de un buen plan que salió mal?

Por último, vaya a buscar una copia de sp_whoIsActive ( http://whoisactive.com/ ) de Adam Machanic y úsela para determinar más sobre las consultas que se están ejecutando. Y si desea poder capturar la salida de sp_whoIsActive, vaya aquí http://www.littlekendra.com/2011/02/01/whoisactive/

De MSDN :

"Las operaciones de inserción se producen en columnas clave ascendentes o descendentes Las estadísticas en columnas clave ascendentes o descendentes, como IDENTIDAD o columnas de marca de tiempo en tiempo real, pueden requerir actualizaciones estadísticas más frecuentes que las que realiza el optimizador de consultas. Las operaciones de inserción agregan nuevos valores a las columnas ascendentes o descendentes . El número de filas agregadas puede ser demasiado pequeño para activar una actualización de estadísticas. Si las estadísticas no están actualizadas y las consultas se seleccionan de las filas agregadas más recientemente, las estadísticas actuales no tendrán estimaciones de cardinalidad para estos nuevos valores. dar como resultado estimaciones de cardinalidad inexactas y un rendimiento de consulta lento.

Por ejemplo, una consulta que selecciona las fechas de pedidos de ventas más recientes tendrá estimaciones de cardinalidad inexactas si las estadísticas no se actualizan para incluir estimaciones de cardinalidad para las fechas de pedidos de ventas más recientes.

Después de las operaciones de mantenimiento Considere actualizar las estadísticas después de realizar procedimientos de mantenimiento que cambien la distribución de datos, como truncar una tabla o realizar una inserción masiva de un gran porcentaje de las filas. Esto puede evitar retrasos futuros en el procesamiento de consultas mientras las consultas esperan actualizaciones de estadísticas automáticas ".

Puede usar "EXEC sp_updatestats" de vez en cuando en su sistema (programado en algún momento) o usar la función STATS_DATE en todos los objetos y ver cuándo se actualizaron sus estadísticas la última vez y si hubo demasiado tiempo desde entonces, use UPDATE ESTADÍSTICAS para ese objeto en particular. En mi experiencia, incluso con las estadísticas automáticas habilitadas, todavía estamos obligados a actualizar las estadísticas de vez en cuando, debido a las operaciones de inserción que no activaron la actualización automática.

Para agregar mi código personal (usado en un trabajo semanal que construye declaraciones dinámicas para la actualización de estadísticas):

select distinct
        'update statistics [' + stats.SchemaName + '].[' + stats.TableName + ']'
            + case when stats.RowCnt > 50000 then ' with sample 30 percent;'
            else 
                ';' end
        as UpdateStatement
    from (
        select
            ss.name SchemaName,
            so.name TableName,
            so.id ObjectId,
            st.name AS StatsName, 
            STATS_DATE(st.object_id, st.stats_id) AS LastStatisticsUpdateDate
            , si.RowModCtr
            , (select case si2.RowCnt when 0 then 1 else si2.RowCnt end from sysindexes si2 where si2.id = si.id and si2.indid in (0,1)) RowCnt
        from sys.stats st
            join sysindexes si on st.object_id = si.id and st.stats_id = si.indid
            join sysobjects so on so.id = si.id and so.xtype = 'U' --user table
            join sys.schemas ss on ss.schema_id = so.uid
    ) stats
    where cast(stats.RowModCtr as float)/cast(stats.RowCnt as FLOAT)*100 >= 10 --more than 10% of the rows have changed
    or ( --update statistics that were not updated for more than 3 months (and rows no > 0)
        datediff(month, stats.LastStatisticsUpdateDate, getdate()) >= 3
        and stats.RowCnt > 0
    )

Aquí obtengo todos los objetos en los que no se actualizaron las estadísticas durante más de 3 meses o desde la última actualización de estadísticas, se modificó más del 10% de las filas.

Supongo que una o más de sus tablas se están volviendo lo suficientemente grandes como para no alcanzar el 20% de los cambios necesarios para ayudar a marcar esas estadísticas actuales como obsoletas para que las Estadísticas de actualización automática entren en acción y, sin embargo, haya suficientes actualizaciones (o inserciones ) que tener estadísticas actualizadas ayudaría mucho. Encontré lo mismo recientemente en un entorno particular después de actualizar de SQL 2000 a SQL 2008.

Además de los otros sitios mencionados en las respuestas anteriores, sugeriría consultar los siguientes recursos en línea.

1) Red-Gate tiene una serie de libros electrónicos gratuitos disponibles para descargar, incluidos "SQL Server Statistics" de Holger Schmeling, donde encontrará la siguiente cita:

http://www.red-gate.com/our-company/about/book-store/

"las tablas con más de 500 filas al menos el 20% de los datos de una columna tuvieron que cambiarse para invalidar cualquier estadística vinculada"

2) SQL Sentry tiene una herramienta gratuita Plan Explorer que ayuda a rastrear problemas dentro de un plan SQL, como una estimación de demasiadas o muy pocas filas en comparación con el número real de filas para una tabla dada en una consulta. Simplemente guarde el plan de ejecución real de SSMS y luego recorra las diferentes partes del plan utilizando Plan Explorer. No es que la información no esté disponible en SSMS usando el plan de ejecución gráfico, pero la herramienta de SQL Sentry hace que sea mucho más fácil de ver.

http://www.sqlsentry.com/plan-explorer/sql-server-query-view.asp

3) Consulte la fecha de actualización de estadísticas usted mismo para ver las tablas en las consultas que más le interesen usando STATS_DATE (), puede encontrar una consulta rápida para obtener las estadísticas más antiguas utilizando una consulta que se encuentra en la siguiente discusión.

http://blog.sqlauthority.com/2010/01/25/sql-server-find-statistics-update-date-update-statistics/

¡Espero que esto ayude!

¡Creo que disfrutarás especialmente el libro de Red-Gate!

-Jeff