DBCC freeproccache?

Sus preguntas están por todas partes, así que intentaré responderlas a todas. La caché de procedimientos es muy grande. Su caché de procedimientos puede estar llena de planes de un solo uso (esto no tiene impacto en las estadísticas, aunque las estadísticas pueden afectar la caché del plan). Puede leer muchos detalles sobre los planes de un solo uso en la publicación de blog de Kimberly Tripp, «Caché de planes y optimización para cargas de trabajo adhoc», incluida una consulta contra sys.dm_exec_cached_plans que le ayudará a identificar cuándo la caché se llena con muchos planes de un solo uso. Como sugiere, puede evitar esta hinchazón utilizando optimize para cargas de trabajo ad hoc. Si encuentra la necesidad de hacer esto a menudo, diría que programar freeproccache como trabajo es una tirita, no una solución.

Para limpiar un plan «malo», primero debe identificar el plan «malo». Esto podría ser un plan que excede un cierto tamaño y / o no se ha ejecutado en algún tiempo, o que ha identificado por una consulta de larga duración, etc. Desafortunadamente, no es fácil identificar un plan que es víctima de la detección de parámetros, a menos que ya conozca la consulta o consultas que se ven afectadas. Supongamos que desea encontrar los planes más antiguos en el caché que no se han ejecutado en más de una semana:

;WITH x AS ( SELECT TOP 10 qs., qs.plan_handle, txs = qs.statement_start_offset, txe = qs.statement_end_offset, = cp.size_in_bytes, = SUM(cp.usecounts), = MAX(qs.last_execution_time) FROM sys.dm_exec_query_stats AS qs INNER JOIN sys.dm_exec_cached_plans AS cp ON qs.plan_handle = cp.plan_handle WHERE qs.last_execution_time < DATEADD(DAY, -7, CURRENT_TIMESTAMP) GROUP BY qs., qs.plan_handle, cp.size_in_bytes, qs.statement_start_offset, qs.statement_end_offset ORDER BY DESC) SELECT x.plan_handle, size, uses, , = COALESCE(NULLIF( SUBSTRING(t., x.txs/2, CASE WHEN x.txe = -1 THEN 0 ELSE (x.txe - x.txs)/2 END ), ''), t.) FROM x CROSS APPLY sys.dm_exec_sql_text(x.) AS t;

Ahora necesita verificar que realmente desea limpiar este plan. Por ejemplo, si reconoce que la consulta es algo que el CEO podría realizar mañana, tal vez sea mejor dejarla ahí. Si quieres borrar el plan, puedes hacerlo directamente diciendo:

DBCC FREEPROCCACHE();

Esto suena como mucho más trabajo que ejecutar DBCC FREEPROCCACHE globalmente, pero si tiene muchos buenos planes en la caché, ciertamente será mejor para sus usuarios en general.

Aún así, esto realmente suena como una tirita. Si su caché se está llenando de basura y el rendimiento se va al inodoro hasta que libera la caché, debe buscar un nivel más alto en la arquitectura, cómo se envían las consultas, etc. Este es el comportamiento que esperaría de la primera iteración de LINQ2SQL, donde almacenaría en caché una versión de un plan para una consulta para cada argumento de cadena que tuviera una longitud diferente. Así que si usted tenía un parámetro de ‘enero’ obtendrá un plan diferente que con un parámetro de ‘febrero’, porque sería definir el tipo de datos como VARCHAR(7) vs VARCHAR(8). Estoy bastante seguro de que el comportamiento es fijo, pero no conozco lo suficiente sobre su entorno / aplicación para sugerir dónde buscar precisamente «malas ideas».»