Dimensione del campione e durata delle STATISTICHE DI AGGIORNAMENTO:è importante?

Per qualsiasi nuovo database creato in SQL Server, il valore predefinito per l'opzione Statistiche di aggiornamento automatico è abilitato . Sospetto che la maggior parte dei DBA lasci l'opzione abilitata, poiché consente all'ottimizzatore di aggiornare automaticamente le statistiche quando vengono invalidate e generalmente si consiglia di lasciarla abilitata. Le statistiche vengono aggiornate anche quando gli indici vengono ricostruiti e, sebbene non sia raro che le statistiche siano ben gestite tramite l'opzione di aggiornamento automatico delle statistiche e tramite le ricostruzioni degli indici, di tanto in tanto un DBA potrebbe ritenere necessario impostare un lavoro regolare per aggiornare un statistica o insieme di statistiche.

La gestione personalizzata delle statistiche spesso implica il comando UPDATE STATISTICS, che sembra abbastanza benigno. Può essere eseguito per tutte le statistiche per una tabella o una vista indicizzata o per una statistica specifica. È possibile utilizzare il campione predefinito, specificare una frequenza di campionamento specifica o un numero di righe da campionare oppure utilizzare lo stesso valore di campionamento utilizzato in precedenza. Se le statistiche vengono aggiornate per una tabella o una vista indicizzata, puoi scegliere di aggiornare tutte le statistiche, solo le statistiche dell'indice o solo le statistiche delle colonne. E infine, puoi disabilitare l'opzione di aggiornamento automatico delle statistiche per una statistica.

Per la maggior parte dei DBA, la considerazione più importante potrebbe essere quando per eseguire l'istruzione UPDATE STATISTICS. Ma i DBA decidono anche, consapevolmente o meno, la dimensione del campione per l'aggiornamento. La dimensione del campione selezionata può influire sulle prestazioni dell'aggiornamento effettivo, nonché sulle prestazioni delle query.

Comprendere gli effetti della dimensione del campione

La dimensione del campione predefinita per UPDATE STATISTICS deriva da un algoritmo non lineare e la dimensione del campione diminuisce all'aumentare della dimensione della tabella, come ha mostrato Joe Sack nel suo post, Test di campionamento predefinito delle statistiche di aggiornamento automatico. In alcuni casi, la dimensione del campione potrebbe non essere sufficientemente ampia per acquisire informazioni interessanti sufficienti o il destra informazioni, per l'istogramma delle statistiche, come notato da Conor Cunningham nel suo post sui tassi di campionamento delle statistiche. Se il campione predefinito non crea un buon istogramma, i DBA possono scegliere di aggiornare le statistiche con una frequenza di campionamento più elevata, fino a un FULLSCAN (scansione di tutte le righe nella tabella o vista indicizzata). Ma come menzionato da Conor nel suo post, la scansione di più righe ha un costo e il DBA deve decidere se eseguire un FULLSCAN per provare a creare l'istogramma "migliore" possibile, o campionare una percentuale più piccola per ridurre al minimo l'impatto sulle prestazioni di l'aggiornamento.

Per cercare di capire a che punto un campione impiega più tempo di un FULLSCAN, ho eseguito le seguenti istruzioni rispetto alle copie della tabella SalesOrderDetail che sono state ingrandite utilizzando lo script di Jonathan Kehayias:

Avevo tre copie della tabella SalesOrderDetailEnlarged, con le seguenti caratteristiche*:

*Ulteriori dettagli sull'hardware sono alla fine di questo post.

Tutte le copie della tabella avevano le seguenti statistiche e nessuna delle tre statistiche dell'indice includeva colonne:

Ho eseguito le istruzioni UPDATE STATISTICS di cui sopra quattro volte ciascuna sulla tabella SalesOrderDetailEnlarged sul mio laptop e due volte ciascuna sulle tabelle SalesOrderDetailEnlarged sul TestServer. Le istruzioni venivano eseguite ogni volta in ordine casuale e la cache delle procedure e la cache del buffer venivano cancellate prima di ogni istruzione di aggiornamento. La durata e l'utilizzo di tempdb per ogni set di istruzioni (media) sono nei grafici seguenti:

Durata media – Aggiorna tutte le statistiche per SalesOrderDetailEnlarged

Utilizzo tempdb – Aggiorna tutte le statistiche per SalesOrderDetailEnlarged

Le durate per la tabella di 23 milioni di righe erano tutte inferiori a tre minuti e sono descritte più dettagliatamente nella sezione successiva. Per la tabella sui dischi SSD_2, l'istruzione FULLSCAN ha impiegato 1492 secondi (quasi 25 minuti) e l'aggiornamento con un campione del 25% ha impiegato 2051 secondi (oltre 34 minuti). Al contrario, sui dischi da 15K, l'istruzione FULLSCAN ha richiesto 2864 secondi (oltre 47 minuti) e l'aggiornamento con un campione del 25% ha richiesto 2147 secondi (quasi 36 minuti), meno del tempo FULLSCAN. Tuttavia, l'aggiornamento con un campione del 50% ha richiesto 4296 secondi (oltre 71 minuti).

L'utilizzo di tempdb è molto più coerente, mostrando un aumento costante all'aumentare della dimensione del campione e utilizzando più spazio tempdb rispetto a un FULLSCAN compreso tra il 25% e il 50%. Ciò che è degno di nota qui è che UPDATE STATISTICS fa usa tempdb, importante da ricordare quando si ridimensiona tempdb per un ambiente SQL Server. L'utilizzo di tempdb è menzionato nella voce UPDATE STATISTICS BOL: