SQL Server comanda di cancellare le cache prima di eseguire un confronto delle prestazioni

Quando si confrontano i tempi di esecuzione di due query diverse, è importante svuotare la cache per assicurarsi che l'esecuzione della prima query non modifichi le prestazioni della seconda.

In una ricerca Google, ho potuto trovare questi comandi:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

In effetti, le mie domande stanno richiedendo un tempo più realistico per essere completato dopo diverse esecuzioni rispetto a prima. Tuttavia, non sono sicuro che questa sia la tecnica consigliata.

Qual è la migliore pratica?

Personalmente, per una query comune la seconda e le successive esecuzioni contano di più.

Stai testando l'IO del disco o le prestazioni della query?

Supponendo che la query venga eseguita spesso ed è fondamentale, quindi si desidera misurarla in condizioni di vita reali. E non vuoi cancellare le cache del server prod ogni volta ...

Se vuoi, puoi:

• DBCC DROPCLEANBUFFERScancella le pagine pulite (non modificate) dal pool di buffer
  Precedere che con CHECKPOINTa svuotare prima tutte le pagine sporche sul disco
• DBCC FLUSHPROCINDB cancella i piani di esecuzione per quel database

Vedi anche (su DBA.SE)

• Risoluzione di tempi di caricamento elevati della pagina mediante SQL Profiler

Risposta tardiva ma può essere utile per altri lettori

DBCC DROPCLEANBUFFERS è un comando spesso utilizzato per il test delle query e la misurazione della velocità di esecuzione delle query. Questo comando (quando eseguito) lascia solo le pagine sporche, che in realtà è una piccola porzione di dati. Rimuove tutte le pagine pulite per un intero server.

Si noti che questo comando non deve essere eseguito nell'ambiente di produzione. L'esecuzione di questo comando comporterà cache buffer per lo più vuota. Eseguire qualsiasi query dopo aver eseguito il comando DBCC DROPCLEANBUFFERS, utilizzerà le letture fisiche per riportare i dati nella cache, che molto probabilmente sarà molto più lento della memoria.

Ancora una volta, tratta questo comando in modo simile a DBCC FREEPROCCACHE - non dovrebbe essere eseguito su nessun server di produzione a meno che tu non sappia assolutamente cosa stai facendo.

Questo può essere un utile strumento di sviluppo perché è possibile eseguire ripetutamente una query in un ambiente di test delle prestazioni senza alcuna variazione di velocità / efficienza a causa della memorizzazione nella cache dei dati.

Ulteriori informazioni su: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

Mi è sempre stato detto di usare:

dbcc dropcleanbuffers;

Da MSDN :

Utilizzare DBCC DROPCLEANBUFFERS per testare le query con una cache buffer fredda senza arrestare e riavviare il server.

Per eliminare i buffer puliti dal pool di buffer, utilizzare innanzitutto CHECKPOINT per produrre una cache buffer fredda. Ciò impone che tutte le pagine sporche per il database corrente vengano scritte su disco e pulisce i buffer. Dopo aver effettuato l'operazione, è possibile emettere il comando DBCC DROPCLEANBUFFERS per rimuovere tutti i buffer dal pool di buffer.

Le altre risposte sono corrette sui motivi per cui non possono essere eseguite DBCC FREEPROCCACHE. Tuttavia, ci sono anche un paio di ragioni per farlo:

1. Consistenza

Se si desidera confrontare due diverse query o procedure che stanno tentando di fare la stessa cosa in modi diversi, è probabile che colpiscano le stesse pagine. Se esegui in modo ingenuo la query n. 1, quindi la query n. 2, la seconda potrebbe essere molto più veloce semplicemente perché quelle pagine sono state memorizzate nella cache dalla prima query. Se si svuota la cache prima di ogni esecuzione, iniziano su un piano uniforme.

Se si desidera testare le prestazioni della hot cache, assicurarsi di eseguire le query più volte, alternando e scartare le prime due esecuzioni. Media dei risultati.

2. Peggior prestazioni

Supponi di avere una query che impiega un secondo contro una cache calda ma un minuto con una cache fredda. Un'ottimizzazione che rende la query in memoria più lenta del 20% ma la query associata a IO il 20% più veloce potrebbe essere una grande vittoria: durante le normali operazioni nessuno noterà i 200 ms in più in circostanze normali, ma se qualcosa costringe una query a eseguire su disco, impiegando 48 secondi anziché 60 potrebbe salvare una vendita.

Ciò è meno preoccupante per i sistemi moderni con decine di gigabyte di memoria e archiviazione SAN e SSD relativamente veloce, ma è ancora importante. Se un analista esegue una massiccia query di scansione delle tabelle sul database OLTP che cancella metà della cache del buffer, le query efficienti in termini di archiviazione ti consentiranno di tornare rapidamente alla velocità.