Consentitemi di riassumere (e arrotondare!) I punti dati importanti nel foglio di calcolo:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
Quindi la prima riga mostra le cose cattive, occupando circa i 2/3 della cache del tuo piano (cose che sono per lo più utilizzate solo una volta, con alcune eccezioni molto minori). Devi cercare di sbarazzartene il più possibile. La seconda fila mostra le cose buone. Queste sono le cose che desideri nella cache del tuo piano (piani con un alto livello di riutilizzo). Il resto dei dati è in gran parte irrilevante IMHO. Un altro punto però: si afferma che l'accesso avviene esclusivamente tramite stored procedure, ma se tali procedure utilizzano SQL dinamico, tali istruzioni vengono memorizzate nella cache come AdHocpiani, non come Procpiani.
A partire dal 2008, direi di accendere optimize for ad hoc workloadse passare al problema successivo: ciò richiederebbe la quantità di MB che i tuoi piani monouso attualmente occupano praticamente a zero. Sfortunatamente, nel 2005, le tue opzioni sono piuttosto limitate, a parte il refactoring di quelle stored procedure per utilizzare OPTION (RECOMPILE)SQL dinamico a livello di istruzione e / o meno / nessuna, o l'attivazione della parametrizzazione forzata a livello di database, che cerca di ottenere un migliore riutilizzo del piano da query simili trattando i valori letterali come parametri ai fini della corrispondenza del piano. Esito anche a menzionare le guide di piano perché non sono per i timidi e - come discuterò più avanti in questa risposta - non sono sicuro che valga la pena seguire questo percorso a meno che tu non sappia che la cache del tuo piano è sicuramente la fonte delle tue prestazioni problema.
Ho chiesto @@VERSIONperché, prima di SP2, l'algoritmo per la quantità di memoria che poteva essere allocata nella cache del piano era relativamente instabile. A partire da SP2 lo hanno rafforzato un po '(il cambiamento è documentato e spiegato in questo post e in questo post ). Nel tuo caso, la cache del piano è relativamente piena, quindi non sorprende che tu stia riscontrando mancanze della cache. 26 GB = un limite superiore di 5,8 GB; Vedo ~ 4,5 GB nel foglio di calcolo, ma qui potrebbero esserci alcune differenze di calcolo o di configurazione che non conosco.
Questo articolo di MSDN parla dell'impostazione del optimize for ad hoc workloadsserver aggiunta nel 2008 e menziona il flag di traccia 8032, che ti consentirà di allocare più memoria nelle tue cache (presumibilmente in assenza di questa impostazione a livello di server, che ora consiglio a tutti i nostri clienti, o almeno il 99% che non sono più nel 2005). Non ho mai testato questo flag di traccia su 2005 SP3 o SP4, e onestamente non sono nemmeno sicuro di quando sia stato introdotto. Inoltre non so se risolverà il tuo problema o semplicemente lo sposterà, poiché penso che anche se avessi un po 'più di RAM in più allocata alle cache, lo riempiresti comunque e avresti un sacco di errori di cache a causa della natura di le procedure memorizzate.
O, ovviamente, se c'è persino un problema da risolvere che si collega direttamente alla cache del piano. Solo perché la percentuale di riscontri nella cache non è così alta come ci si potrebbe aspettare non significa che stia causando il tuo problema, e ovviamente il contrario è che anche con un rapporto di riscontri nella cache del 100% - il che non sembra realistico dato che così tanti dei tuoi piani sono monouso e ad hoc: i tuoi utenti potrebbero ancora soffrire di problemi di prestazioni causati da qualcos'altro.
Il mio suggerimento è di cercare pistole fumanti migliori rispetto al piano di riscontro della cache. Ottieni maggiori dettagli sui reclami in merito alle prestazioni dei tuoi utenti. Tutte le query sono sempre lente? Alcune domande? Alcune ore del giorno / settimana / ciclo economico? Le query di segnalazione sono lente? Leggi attentamente questo documento lungo e certamente secco sulle migliori pratiche di SQL Server , in particolare la sezione sulle attese e le code, che può aiutarti a formulare un approccio logico per identificare, diagnosticare e risolvere i problemi di prestazioni. Far apparire un numero in una dashboard migliore - un numero che non conosci nemmeno direttamente contribuisce al problema - potrebbe essere molto soddisfacente, ma se non risolve i problemi di prestazioni dei tuoi utenti, non ti ha davvero ottenuto dovunque.
Questi possono anche essere utili per leggere su compilation / ricompilazione e pianificare il riutilizzo della cache. Alcuni di questi sono focalizzati sul 2008 (in particolare quelli sull'impostazione dei carichi di lavoro ad hoc), ma molte informazioni sono ancora utili per il 2005 e / o per comprendere meglio i vantaggi dell'aggiornamento (suggerimento, suggerimento).