Cuando activa la opción " Optimizar para cargas de trabajo ad hoc ", provocará que las consultas ad-hoc que se ejecutan la segunda vez sean tan lentas como la primera, porque estará compilando un plan de ejecución y extrayendo los mismos datos ( sin caché) esas primeras 2 veces.
Puede que esto no sea un gran problema, pero lo notará cuando pruebe consultas.
Entonces, ¿qué sucede ahora, sin esta opción activada y un caché lleno de consultas Ad-Hoc 1-Off?
El algoritmo de gestión de almacenamiento en caché:
Cuando se introdujo esta función de optimización, también se actualizó el algoritmo de gestión de almacenamiento en caché.
El artículo de Kimberly Tripp también hace referencia a la publicación de Kalen Delaney sobre este cambio de algoritmo.
Ella lo explica mejor:
El cambio en realidad calcula un tamaño de caché del plan en el que SQL Server reconoce que hay presión de memoria y comenzará a eliminar los planes de la caché. Los planes que se eliminarán son los planes baratos que no se han reutilizado, y esto es BUENO.
Esto significa que esos molestos planes de un solo temporizador serán los primeros en irse cuando necesite liberar recursos.
Entonces ahora la pregunta es:
" ¿Por qué NECESITAMOS 'Optimizar para cargas de trabajo ad hoc' cuando SQL Server se encarga de eliminar los planes no utilizados cuando es necesario? "
Mi respuesta a esto es, si regularmente tiene una tonelada de montones dinámicos de sql de anuncios no parametrizados -hoc consultas, entonces tiene mucho sentido activar esta función.
Desea evitar ejercer presión sobre los recursos del sistema, de modo que fuerce la eliminación del plan en caché / datos después de que haya utilizado el espacio máximo de memoria caché.
¿Cómo sé cuándo necesito activar esto?
Aquí hay una consulta que escribí para mostrarle cuántos Planes Ad-Hoc tiene actualmente en caché y cuánto espacio en disco están consumiendo (los resultados cambiarán a lo largo del día, así que pruébelo durante un momento de gran carga):
--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
S.Total_MB_1_Use, S.Total_MB,
CAST( (S.Total_MB_1_Use * 1.0 / S.Total_MB ) as Decimal(18,2) )[Pct_MB_1_Use]
FROM
(
SELECT CP.objtype[CacheType],
COUNT(*)[Total_Plan],
SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
/ 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
FROM sys.dm_exec_cached_plans as CP
GROUP BY CP.objtype
) AS S
ORDER BY S.CacheType
Resultados:
No voy a decir, " Cuando tienes X MB " o " Si X% de tu Ad Hoc es de un solo uso " para activar esto.
No afecta a Sprocs, disparadores, vistas o SQL parametrizado / preparado, solo las consultas ad-hoc.
Mi recomendación personal es activarlo en su entorno de producción, pero considere dejarlo en su entorno de desarrollo.
Digo esto solo para Dev, porque si está optimizando una consulta que tarda un minuto o más en ejecutarse, entonces no desea ejecutarla 3 veces antes de que pueda ver qué tan rápido irá con el almacenamiento en caché, cada una vez que lo edita para encontrar el mejor diseño de optimización.
Si su trabajo no implica hacer esto todo el día, entonces enloquezca y pídale a su DBA que lo encienda en todas partes.