Planes de recreación de SQL Server cada día

Tenemos este problema en nuestro entorno de producción.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Edición Enterprise (64 bits) en Windows NT 6.1 (compilación 7601: Service Pack 1).

SQL Server está eliminando todos (casi el 100% de) los antiguos planes de ejecución y los está recreando todos los días durante la noche (de 11:00 p.m. a 8:00 a.m.). Esto incluso sucedía cuando las 'estadísticas de actualización automática' estaban en estado deshabilitado. Hemos activado las "estadísticas de actualización automática" durante las últimas 2-3 semanas. Pero todavía está sucediendo.

Realmente no sabemos qué desencadena esta nueva generación de planes, pero estamos seguros de que no lo hacemos manualmente.

Lo único que realmente coincide con el momento en que se regeneran los planes es un trabajo de mantenimiento de base de datos que tenemos: la reorganización diaria del índice (cuando la fragmentación es del 5-30%) y la reconstrucción diaria del índice (cuando la fragmentación es más del 30% ) trabajo. Por lo general, este trabajo de mantenimiento diario solo se reorganiza (ya que la fragmentación del índice nunca supera el 30% por día).

Impacto:

Estos planes recién creados hacen que algunas llamadas UDF / llamadas de consulta (que se llaman desde UI / páginas web) tarden más (minutos en lugar de menos de 1 segundo), por lo que las sesiones se acumulan y la CPU se acerca al 90% .

El problema desaparece en el momento en que esas sesiones bloqueadas se eliminan forzosamente (en el lado de la base de datos), y 1) cuando todos los planes de ejecución correspondientes se borran manualmente (para consultas) o 2) cuando se modifican los UDF (para funciones). Cualquier plan nuevo creado por el servidor SQL desde ese momento funciona perfectamente durante todo el día hasta que termina teniendo el mismo problema a la mañana siguiente. Además, este comportamiento no es 100% consistente, realmente no lo estamos viendo todas y cada una de las mañanas. Pero ha habido períodos de tiempo en los que lo hemos visto constantemente durante 4-5 días seguidos.

El problema ocurre en las mañanas de negocios, al parecer, cuando se accede a las páginas web / IU con mayor intensidad.

¿Alguien tiene idea de qué está causando esto y cómo resolver este problema? Cualquier ayuda sería muy apreciada.

Bueno, tengo algunas ideas que podrían causar este comportamiento.

1. ¿Monitorea la presión de su memoria? Tal vez sus consultas eleven un cierto límite que causará el vaciado del caché del plan. No conozco su aplicación, pero ¿esto corresponde con sus registros de sus servidores frontend? ¿Hay presión también durante este tiempo?
2. ¿Tiene un servidor SQL dedicado o el servidor comparte su hardware con otros procesos / servicios? De lo contrario, intente externalizar su SQL Server a una máquina dedicada. Esto reducirá los efectos secundarios de otros servicios.
3. Es posible que desee usar optimize for ad hoc workloads, que solo guardará un trozo de plan y lo compilará si es necesario. Esto reducirá la carga de su plancache, lo que reducirá la posibilidad de un enjuague de plancache. Puedes habilitarlo usando sp_configure 'optimize for ad hoc workloads',1; reconfigure. Esto se puede hacer si ha habilitado el advanced optionsuso sp_configure 'show advanced options',1; reconfigure.
4. Otra idea pueden ser las copias de seguridad. Solo copias de seguridad simples. Si son agresivos, puede ocurrir que su máquina también esté bajo presión. El momento en que menciona solo suena como un buen intervalo de tiempo para planificar una copia de seguridad.
5. Tal vez es un error bastante simple en su secuencia de comandos de mantenimiento. ¿Ha verificado si hay un problema lógico que hace que su script reconstruya todos los índices en lugar de solo aquellos que coinciden con los criterios? Esto quizás también pueda causarlo.

Justo al lado de todas estas posibilidades, puede ser útil para comprobar los archivos de registro para algunos cambios en las opciones affinity mask, affinity I/O masky sus parejas x64. Otra cosa puede ser un cambio de la MAXDOPopción de su instancia. Por favor, compruebe los registros para ellos también. Tendrán que lavar el plancache también.

Por último, pero no menos importante, aún puede ejecutar un seguimiento del lado del servidor (solo configurándolo con el generador de perfiles, iniciarlo, detenerlo y usar el comando sql para iniciarlo nuevamente en el lado del servidor). Al lado perfmonestá tu amigo. Puede observar y controlar sus valores de rendimiento por un tiempo. Tal vez pueda ver paralelismos en la presión con ciertas acciones en su servidor que pueden causar esas descargas.

Esperemos que esto te ayude, incluso si la respuesta llega un poco más tarde.