Quando si attiva l'opzione " Ottimizza per carichi di lavoro ad hoc", le query ad hoc eseguite la seconda volta saranno lente quanto la prima, poiché si compilerà un piano di esecuzione e si estrarranno gli stessi dati ( senza che sia memorizzato nella cache) quelle prime 2 volte.
Questo potrebbe non essere un grosso problema, ma lo noterai quando testerai le query.
Cosa succede ora, senza questa opzione attivata e una cache piena di query 1-Off Ad-Hoc?
L'algoritmo di gestione della cache:
Quando è stata introdotta questa funzionalità di ottimizzazione, è stato aggiornato anche l'algoritmo di gestione della cache.
L'articolo di Kimberly Tripp fa riferimento anche al post di Kalen Delaney su questa modifica dell'algoritmo.
Lo spiega meglio:
La modifica calcola effettivamente una dimensione della cache del piano in base alla quale SQL Server riconosce la pressione della memoria e inizierà a rimuovere i piani dalla cache. I piani da rimuovere sono i piani economici che non sono stati riutilizzati, e questa è una buona cosa.
Ciò significa che quei fastidiosi piani con un solo timer saranno i primi ad andare quando devi liberare risorse.
Quindi ora la domanda diventa:
" Perché ABBIAMO BISOGNO di" Ottimizzare per i carichi di lavoro ad hoc "quando SQL Server si occupa di rimuovere i piani inutilizzati quando necessario? " La
mia risposta è che se si dispone regolarmente di una tonnellata di dinamici sql che generano una gran quantità di annunci non parametrizzati -hoc query, quindi ha perfettamente senso attivare questa funzione.
Si desidera evitare di mettere a dura prova le risorse di sistema, in modo tale da forzare la rimozione di dati / cache dopo aver esaurito lo spazio di memoria della cache massima.
Come faccio a sapere quando devo accenderlo?
Ecco una query che ho scritto per mostrarti quanti piani Ad-Hoc hai attualmente memorizzato nella cache e quanto spazio su disco stanno esaurendo (i risultati cambieranno durante il giorno, quindi testalo durante un periodo di carico pesante):
--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
risultati:
Non dirò " Quando hai X MB " o " Se l'X% dei tuoi annunci ad hoc sono monouso " per attivarlo.
Non influisce su Sprocs, trigger, viste o SQL con parametri / preparati: solo le query ad hoc.
Il mio consiglio personale è di attivarlo nel tuo ambiente di produzione, ma considera di lasciarlo nel tuo ambiente di sviluppo.
Lo dico solo per Dev, perché se stai ottimizzando una query che richiede un minuto o più per essere eseguita, non vuoi eseguirla 3 volte prima di poter vedere quanto velocemente andrà con la cache - ogni una volta che lo modifichi per trovare il miglior design di ottimizzazione.
Se il tuo lavoro non prevede di farlo tutto il giorno, impazzisci e chiedi al tuo DBA di attivarlo ovunque.