Database
 sql >> Database >  >> RDS >> Database

AGGIORNAMENTI alle statistiche

Le ultime numerose versioni di SQL Server hanno introdotto una serie di nuove funzionalità, nonché miglioramenti alle funzionalità esistenti. Un'area del motore che è facile trascurare è la statistica. Dopotutto, le statistiche continuano a essere create allo stesso modo, ti parlano ancora della distribuzione dei dati, sono ancora utilizzate da Query Optimizer... cosa c'è di diverso? La funzione di base delle statistiche rimane la stessa, ma il modo in cui vengono utilizzate da Query Optimizer cambia a seconda dello stimatore di cardinalità che stai utilizzando. Ci sono anche diverse modifiche degne di nota relative all'aggiornamento delle statistiche e sono state aggiunte nuove funzionalità per la visualizzazione delle informazioni statistiche. Complessivamente, queste modifiche nelle ultime versioni possono causare una variazione nel comportamento di SQL Server che non ti aspettavi.

Nota:questo post è più applicabile a SQL Server 2012 e versioni successive, ma sono inclusi alcuni dettagli per le versioni precedenti come riferimento (e divertimento).

SQL Server 7.0

  • Il numero di passaggi in un istogramma è limitato a 300. In SQL Server 6.5 e versioni precedenti un istogramma avrebbe il numero di passaggi che potrebbero rientrare in una pagina di 2 KB, in base alle dimensioni della prima colonna nella chiave.
  • Viene introdotta l'opzione del database "aggiorna automaticamente le statistiche"; in precedenza le statistiche venivano aggiornate solo manualmente.

SQL Server 2000

  • Il numero di passaggi nell'istogramma viene ridotto da 300 a 200 (tecnicamente 201, se includi il passaggio per NULL, supponendo che la prima colonna della chiave consenta NULL).

SQL Server 2005

  • Gli aggiornamenti delle statistiche che utilizzano FULLSCAN possono essere eseguiti in parallelo.
  • I flag di traccia 2389 e 2390 sono stati introdotti in SP1 per aiutare con il problema della chiave crescente, descritto nel post, Chiavi crescenti e Statistiche di correzione rapida automatica. Un esempio dettagliato di questo scenario è fornito nel mio post Trace Flag 2389 e il nuovo Cardinality Estimator.
  • Viene introdotta l'opzione dell'istanza "Aggiorna automaticamente le statistiche in modo asincrono". Si noti che affinché ciò sia attivo, è necessario abilitare anche l'opzione "Aggiorna automaticamente le statistiche". Se non sei chiaro su cosa fa questa opzione, consulta la documentazione in ALTER DATABASE SET Options. Questa è un'impostazione consigliata da Glenn (come indicato nel suo post a cui si fa riferimento di seguito), ma penso che sia importante essere consapevoli dei potenziali problemi, come indicato in Come gli aggiornamenti automatici delle statistiche possono influire sulle prestazioni delle query.

    Nota: È presente una perdita di memoria correlata a questa impostazione in SQL Server 2008 tramite SQL Server 2012; per ulteriori dettagli, vedere il post di Glenn Important Hotfix per SQL Server 2008.

SQL Server 2008

  • Sono state introdotte statistiche filtrate, che possono essere create separatamente da un indice filtrato. Ci sono alcune limitazioni sugli indici filtrati per quanto riguarda il post di Query Optimizer (vedi post di Tim Chapman The Pains of Filtered Indexes e Paul White post Optimizer Limitations with Filtered Indexes), ed è importante comprendere il comportamento del contatore che tiene traccia delle modifiche (e quindi può attivare aggiornamenti automatici). Vedi il post di Kimberly Gli indici filtrati e le statistiche filtrate potrebbero diventare seriamente obsoleti per maggiori dettagli e ti consiglio anche di controllare la sua procedura memorizzata che analizza l'inclinazione dei dati e consiglia dove puoi creare statistiche filtrate per fornire maggiori informazioni a Query Optimizer. L'ho implementato per diversi grandi clienti che hanno VLT e una distribuzione asimmetrica tra le colonne usate frequentemente nei predicati.
  • Sono state aggiunte due nuove viste del catalogo, sys.stats e sys.stats_columns, per fornire una visione più semplice delle statistiche e delle colonne incluse. Usa queste due viste invece di sp_helpstats, che è deprecato e fornisce meno informazioni.

SQL Server 2008R2 SP1

  • È disponibile il flag di traccia 2371, che può essere utilizzato per ridurre il numero di modifiche necessarie per l'aggiornamento automatico delle statistiche. Come promemoria, sono un fan dell'aggiornamento delle statistiche su base regolare tramite un lavoro pianificato e di lasciare l'aggiornamento automatico abilitato per sicurezza.

SQL Server 2008R2 SP2

  • È inclusa la funzione sys.dm_db_stats_properties, che fornisce le stesse informazioni presenti nell'intestazione di DBCC SHOW_STATISTICS, nonché una colonna di modifica che può essere utilizzata per tenere traccia delle modifiche e determinare a livello di codice se era necessario un aggiornamento. Ricordi la mia preferenza per l'utilizzo di un lavoro per aggiornare le statistiche? Quel lavoro è diventato molto più intelligente con questo DMF... ora posso vedere quanti dati sono stati modificati e aggiornare le statistiche SOLO se una certa percentuale di dati è cambiata. Slick.

SQL Server 2012

  • L'aggiornamento delle statistiche non comporterà l'annullamento dei piani SE nessuna riga è stata modificata. Questo è uno che sorprende molte persone e Kimberly ha un post divertente, Cosa ha causato l'orribile errore di quel piano:dovresti aggiornare le statistiche?, che ripercorre la sua avventura per capirlo.

SQL Server 2012 SP1

  • DBCC SHOW_STATISTICS richiede solo l'autorizzazione SELECT – in precedenza richiedeva che un utente fosse un membro di sysadmin o un membro del ruolo del database db_owner o db_ddladmin. Questo può essere disabilitato globalmente con il flag di traccia 9485.
  • Include sys.dm_db_stats_properties (vedi nota 2008R2 SP2 sopra)

SQL Server 2012 SP2

  • L'aggiornamento cumulativo 1 introduce una correzione relativa alle chiavi ascendenti che non vengono identificate correttamente anche con i flag di traccia 2389 e 2390 in uso. Ciò richiede il flag di traccia 4139 oltre a CU1, come indicato in KB 2952101.

SQL Server 2014

  • Viene introdotto il nuovo Cardinality Estimator, implementato impostando la modalità di compatibilità del database a 120, oppure utilizzando il flag di traccia 2312. Se non hai letto nulla sul nuovo CE ti consiglio di iniziare con la documentazione di Cardinality Estimation e poi di leggere Joe White paper di Sack, Ottimizzazione dei piani di query con lo strumento per la stima della cardinalità di SQL Server 2014, per dettagli approfonditi.
  • Il comportamento dei flag di traccia 2389 e 2390 per le chiavi ascendenti è ora implementato tramite la modalità di compatibilità del database. Se la modalità di compatibilità dei database è impostata su 120 (o superiore nelle versioni successive), non è necessario utilizzare i flag di traccia 2389 e 2390 per SQL Server per identificare le statistiche con chiavi ascendenti.
  • Le statistiche incrementali vengono introdotte per le partizioni e possono essere visualizzate tramite il nuovo DMF sys.dm_db_incremental_stats_properties. Le statistiche incrementali forniscono un modo per aggiornare le statistiche per una partizione senza aggiornarle per l'intera tabella. Tuttavia, le informazioni statistiche aggiuntive delle statistiche incrementali non vengono utilizzate da Query Optimizer, ma vengono raggruppate nell'istogramma principale della tabella.
  • CU2 include la stessa correzione menzionata sopra per SQL Server 2012 SP2 che richiede anche il flag di traccia 4139.

SQL Server 2014 SP1

  • Il flag di traccia 7471 è stato trasferito su CU6, originariamente disponibile in SQL Server 2016 come indicato di seguito.

SQL Server 2016

  • Il flag di traccia 2371 non è più necessario per ridurre la soglia per gli aggiornamenti automatici delle statistiche se la modalità di compatibilità del database è impostata su 130. Vedere Controllo del comportamento di Autostat (AUTO_UPDATE_STATISTICS) in SQL ServerSQL Server.
  • Gli aggiornamenti delle statistiche possono essere eseguiti in parallelo quando si utilizza SAMPLE, non solo FULLSCAN. Questo è legato alla modalità di compatibilità (deve essere 130), ma può potenzialmente fornire aggiornamenti più rapidi e quindi ridurre le finestre di manutenzione. Aaron Bertrand parla di questo miglioramento nel suo post, Un potenziale miglioramento per gli aggiornamenti delle statistiche:MAXDOP.
  • Il flag di traccia 7471 è stato introdotto in CU1 per consentire l'esecuzione simultanea di più comandi UPDATE STATISTICS per una singola tabella e Jonathan fornisce alcuni ottimi esempi di come questo può essere utilizzato nel suo post Supporto migliorato per ricostruzioni statistiche parallele.

SQL Server 2016 SP1

  • Viene introdotta l'opzione del suggerimento per la query ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS, insieme all'argomento FOR HINT, che è l'equivalente del flag di traccia 4139.
  • Il DMF sys.dm_db_stats_histogram è esposto in CU2, che è un'alternativa all'output dell'istogramma da DBCC SHOW_STATISTICS. Le informazioni in entrambi sono le stesse, usa ciò che è più facile per te o si adatta meglio al problema che devi risolvere.
  • L'opzione PERSIST_SAMPLE_PERCENT è stata introdotta in CU4, che può essere utilizzata per forzare l'uso della stessa frequenza di campionamento ogni volta che una statistica viene aggiornata in futuro, ed esempi di questo comportamento possono essere trovati nel post, Frequenza di campionamento delle statistiche persistenti.

SQL Server 2017

  • L'opzione PERSIST_SAMPLE_PERCENT è disponibile in CU1 (vedi voce SP1 2016 per ulteriori informazioni).
  • Gli attributi StatsInfoType e OptimizerStatsUsageType vengono aggiunti al Query Plan, che elenca le statistiche utilizzate durante l'ottimizzazione della query. Questo è disponibile in CU3 ed è legato alla versione CE (120 e successive). Questo è abbastanza bello! Non ho ancora avuto la possibilità di giocare con questo, ma per ottenere queste informazioni in precedenza dovevi usare flag di traccia non documentati.
  • CU3 ha anche introdotto l'opzione MAXDOP per CREATE STATISTICS e UPDATE STATISTICS, che può essere utilizzata per sovrascrivere il valore MAXDOP per l'istanza o il database.
  • Un'altra aggiunta in CU3:gli attributi UdfCpuTime e UdfElapsedTime si trovano nel Query Plan, che rappresentano le statistiche di esecuzione per UDF con valori scalari.

Riepilogo

Se stai cercando di eseguire l'aggiornamento a una versione più recente o se hai eseguito l'aggiornamento di recente, prendi nota dell'impatto di queste modifiche sulla tua soluzione. Molti clienti ci hanno contattato dopo l'aggiornamento da 2005/2008/2008R2 a 2014 o 2016, lamentandosi di problemi di prestazioni. In molti casi, prima dell'aggiornamento non sono stati completati test adeguati.

Questo è qualcosa su cui ci concentriamo davvero quando aiutiamo l'aggiornamento di un client. Al di là dei passaggi per spostare un'istanza di produzione da una versione all'altra con tempi di inattività ridotti, vogliamo assicurarci che il giorno successivo all'aggiornamento sia noioso per i DBA e gli sviluppatori.

Non testiamo semplicemente il processo di aggiornamento, testiamo l'aspetto del sistema dopo l'aggiornamento. Gli stessi flag di traccia del vecchio ambiente sono necessari nel nuovo? Quali impostazioni del database devono essere modificate? Le prestazioni delle query cambiano, in meglio o in peggio? Se non conosci le risposte a queste domande prima di aggiornare la produzione, ti stai preparando per uno o molti giorni di vigili del fuoco, chiamate Sev 1, pasti alla scrivania, non abbastanza sonno e chissà cos'altro .

Prenditi del tempo in anticipo per comprendere l'impatto delle nuove funzionalità e delle modifiche alle funzionalità sopra elencate, pianificare l'aggiornamento e testare il più possibile.