Elenco definitivo di passaggi per il test di base di SQL Server?

Prima di eseguire un test delle prestazioni / baseline per un'app che utilizza SQL Server, voglio essere in grado di impostare l'istanza su uno stato "pulito", senza riavviare l'istanza. Ci sono passaggi che tendo a seguire, ma voglio costruire un elenco definitivo che sia nella sequenza corretta e che non abbia passaggi ridondanti.

Questo elenco di passaggi consente di impostare SQL Server su uno stato "pulito"?

La sequenza è logica / corretta?

Ci sono passaggi ridondanti?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Eric Higgins
fonte

Cordiali saluti, DROPCLEANBUFFERSè bello per i test ma non sempre accurati. Se fai riferimento a una tabella ad alto volume, è molto probabile che avrai quasi sempre pagine in memoria e il tempo di I / O non sarà un grande fattore in quella query. Potresti dare più peso all'IO di quanto sia realistico in quel caso.

— JNK,

Stai parlando di test in un ambiente di produzione o in un ambiente di test isolato?

— bopapa_1979,

Chiunque esegua i test in un ambiente Prod dovrebbe essere licenziato. :) Sì, ambienti di test.

— Eric Higgins,

Innanzitutto, vorrei fare un passo indietro e chiedere quali misure intendi raccogliere durante il test. Se si contano letture logiche per query, ad esempio, non è necessario liberare la cache. Sono un grande fan dell'utilizzo delle letture logiche perché è indipendente dal fatto che i dati siano memorizzati nella cache o su disco - e in produzione, è difficile indovinare se i dati di una query verranno memorizzati nella cache o meno (a meno che non si memorizzi nella cache l'intero database in memoria) . Se ti sintonizzi per ridurre al minimo le letture logiche, l'app andrà più veloce indipendentemente dal fatto che i dati siano nella cache o meno.

Quindi, mi chiedo cosa sta cambiando tra le piste. Ad esempio, eseguendo EXEC SP_UPDATESTATS in ciascun database come hai suggerito, ricampionerai le statistiche per le tabelle che sono state aggiornate. Tuttavia, a meno che non si stiano aggiornando le statistiche con fullscan, si ottengono righe casuali dalla tabella - non è troppo ripetibile e non penso che tu voglia davvero farlo. Invece, potresti voler ripristinare i database tra ogni esecuzione in modo da testare sempre esattamente gli stessi dati. Se i tuoi test eseguono inserimenti / aggiornamenti / eliminazioni, potrebbero avere profili di rendimento diversi su ogni esecuzione se non stai ripristinando il database (perché stanno aggiungendo / modificando dati, oltre a modificare le statistiche sui dati) - e ancora peggio,

— Brent Ozar
fonte

Ottimi punti, l'obiettivo è quello di avere tutto identico tra le corse. Le misure che sto prendendo in questo caso a mano sono tempi di esecuzione per funzioni specifiche in un'app (x secondi per tornare all'elenco in app, y secondi per aggiungere un elemento in coda, ecc.). Ciò che sta cambiando tra i test potrebbe essere pezzi di codice app e non oggetti SQL, oggetti SQL e non codice app o impostazioni a livello di istanza / DB come la concorrenza senza modifiche al codice app. Se dovessi aggiungere un ripristino fuori dal gate prima di ogni test, come ti senti sulla mia lista sopra @ quel punto? Mi manca qualcosa o la sequenza richiede un po 'di lavoro?

— Eric Higgins,

Brent, stai prendendo in considerazione la CPU nei tuoi test?

— AK,

@EricHiggins Piuttosto che testare più cose contemporaneamente, testerei i pezzi singolarmente. Preferirei testare direttamente le query e vedere quali cambiamenti influiscono sulle prestazioni lì. Ad esempio, esegui una traccia SQL mentre esegui funzioni specifiche nell'app, quindi continua a riprodurre quella traccia mentre apporti modifiche all'indice / configurazione per migliorare le prestazioni e osserva cose come letture logiche e metriche della CPU nelle tracce.

— Brent Ozar,

@AlexKuznetsov In realtà non sono io a fare i test: Eric è quello che ha posto la domanda. Quando faccio questo tipo di lavoro, guardo le metriche della CPU a livello di query e il server in generale.

— Brent Ozar,

Utilizziamo un generatore di carico di terze parti (e abbiamo una persona a tempo pieno dedicata allo sviluppo di test di carico). Quindi i miei test sono precisi per la transazione, la sequenza, il numero di utenti, i passaggi esatti eseguiti nell'app ... tutto. Quindi non ho necessariamente bisogno di esaminare le metriche del tipo di dashboard SQL. Il software di test del carico tiene traccia dei millisecondi dei tempi di risposta dei moduli dell'app. Quindi fare un ripristino del DB è una buona idea. Devo controllare la sanità mentale gli altri passaggi che sto facendo per essere sicuro di raggiungere lo stato "Clean ardesia" che sto cercando prima di ogni ciclo di test.

— Eric Higgins,