Nuovo cardinalità stimatore (SQL Server 2014) è lontano

Question

Ho un database data warehouse e sto affrontando problemi con il nuovo cardinalità stimatore di SQL Server 2014.

Dopo l'aggiornamento del server di database di SQL Server 2014 I ho osservato una grande differenza nelle prestazioni delle query. Alcune query vengono eseguite molto più lentamente (30 secondi in SQL 2012 e 5 minuti in SQL 2014). Dopo aver esaminato i piani di esecuzione, ho visto che le stime di cardinalità su SQL Server 2014 sono lontane e non riesco a trovarne una ragione.

Ecco un esempio di un piano di esecuzione di query (operatore in alto a sinistra) in SQL 2012 contro SQL 2014:

Alcuni dettagli:

• mie domande sono dati tipici query di carico della tabella dei fatti di magazzino. Faccio una query su una tabella transazionale e mi unisco a una tabella di dimensioni lotto (15-20) (c'è sempre o 0 o 1 record che è unito dalla tabella dimensionale).

• Ho aggiornato le statistiche di tutte le tabelle (con FULLSCAN) per essere sicuri che le statistiche siano aggiornate.

• Le chiavi aziendali delle tabelle delle dimensioni sono indicizzate (indice univoco non protetto). Mi sembra che, a causa dell'unicità di questo indice, il vecchio stimatore di cardinalità (SQL 2012) presupponga correttamente che non ci sia il massimo. 1 record che si aggiunge (il numero stimato di record non cambia nel piano di esecuzione).

ho cercato di restringere la questione al più semplice esempio - Seleziona con 2 unisce:

Ecco la stima di cardinalità per gli operatori 1 e 2 in SQL 2012 contro SQL 2014:

  | Est.rows - SQL2012 | Est.rows - SQL2014 
Operator 1 |    7653 |    7653 
Operator 2 |    7653 |    10000 

Come si può vedere, SQL Server 2014 non trova la stima di oltre il 30% (10000 vs 7653). Perché ho cca. 15-20 join in una query tipica, la stima finale va via.

Posso mettere il database nella modalità di compatibilità inferiore (110) e funziona perfettamente (come su SQL Server 2012), ma mi piacerebbe davvero sapere qual è la ragione di questo comportamento. Perché il risultato dello stimatore di cardinalità di SQL Server 2014 è errato?

Answer 1

Penso che oggi non ci sia una risposta semplice a questa interessante domanda. La migliore risposta che conosco è il seguente video: http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/DBI-B331#fbid=. Ha numerosi esempi di stimatori nuovi e vecchi. Il video dura circa 50+ minuti ma ne vale la pena.

Una sintesi del video che si riferisce a questa domanda:

vecchie ipotesi di stime di cardinalità:

1. Uniformità - dati è uniformemente distribuito.
2. Indipendenza: la colonna 1 non ha alcuna relazione con la colonna 2.
3. Contenimento: quando due attributi possono essere uguali, si presuppone che siano gli stessi.
4. Inclusione: dovrebbe esserci una corrispondenza.

di utilizzare SQL Server 2012 cardinalità stimatore in SQL Server 2014 l'uso la seguente opzione:

• Opzione (querytraceon 9481) --revert al 2012

ciò che è nuovo stimatore facendo (in base al video):

• SQL Server utilizza la selettività media nell'indice e stima nu mber di righe moltiplicando la densità della chiave per il numero totale di righe nell'indice.
• Il nuovo stimatore non funziona molto bene con le distribuzioni irregolari.
• La maggior parte delle differenze tra gli stimatori si basa sulla clausola WHERE.
• Un nuovo stimatore di cardinalità ritiene che esista una correlazione tra le tabelle.
• È possibile creare statistiche filtrate per migliorare le query. (http://msdn.microsoft.com/en-us/library/ms188038.aspx)

fare/checklist:

1. Auto Create/Update Stats 
2. Check database compatibility mode (120/110) 
3. Test using query trace flags 
4. XML showplan 

Aggiornamento Cosa c'è di nuovo in cardinalità stimatore (SQL Server 2016)

1. La più accurata.
2. La CE prevede quante righe la query sarà probabilmente tornare
3. SQL Server 2016 il negozio di query
4. Un'altra opzione per il monitoraggio delle previsioni cardinalità della CE è quello di utilizzare l'evento esteso chiamato query_optimizer_estimate_cardinality
5. CE capisce massima valore potrebbe essere superiore rispetto a quando le statistiche loro ultima riuniti capisce
6. CE che predicati filtrati sulla stessa tabella sono spesso correlate
7. CE non assume alcuna correlazione tra predicati filtrati da diverse tabelle

Maggiori dettagli:

https://docs.microsoft.com/en-us/sql/relational-databases/performance/cardinality-estimation-sql-server

https://www.sqlshack.com/query-optimizer-changes-in-sql-server-2016-explained/

Answer 2

Mi chiedo se si esegue in questo problema intorno stime di selettività più colonne:

http://www.sqlskills.com/blogs/kimberly/multi-column-statistics-exponential-backoff/

sembra che non ci sono ancora alcune stranezze con il nuovo CE prova anche ad usare TF 4137 come delineato e vedere se questo aiuta.

infine assicurarsi che siete sulle ultime CU e si esegue con il TF 4199 a coperta consentire tutte le correzioni di query optimizer come prova sempre questo in un ambiente non di produzione, se possibile, prima e essere consapevoli di regressioni in altre query quando attivare le impostazioni globalmente

Answer 3

Questa non è una risposta diretta a questa domanda, ma potrebbe aiutare coloro che stanno affrontando problemi di prestazioni simili relativi a quel database SCCM (noto come ConfigMgr) relativo alle modifiche di Cardinality Estimator (CE). Le query SQL possono scadere o la console ConfigMgr può essere lenta a causa delle nuove modifiche di Cardinality Estimator (CE) in SQL Server 2014 e SQL Server 2016. Microsoft ha fornito una soluzione a questo problema here che suggerisce di applicare uno stimate cardinality stimatore SQL appropriato (CE) livello di compatibilità come mostrato nella tabella sottostante:

SQL Server version Supported compatibility  Recommended compatibility 
         level values     level for ConfigMgr 

SQL Server 2016  130, 120, 110, 100   130 

SQL Server 2014  120, 110, 100     110 

Spero che questo aiuti!