Le performance di un database sono strettamente legate al funzionamento del suo componente più "intelligente", il query processor, ai dati presenti nel database stesso, alle query che vengono scritte e - importantissime - alle stime di distribuzione dei dati che ogni RDBMS si mantiene per poter fare al meglio il proprio lavoro. In questa sessione vederemo come tutte queste cose concorrono a produrre performance ottimali - o meno - in SQL Server

1. Template designed by
Query Processor & Statistics
Davide Mauri
dmauri@solidq.com
www.davidemauri.it

2. brought to you by

3. Works with SQL Server from 6.5, on BI from 2003
Specialized in Data Solution Architecture, Database Design,
Performance Tuning, BI
Microsoft SQL Server MVP
President of UGISS (Italian SQL Server UG)
Mentor @ SolidQ
Regular Speaker @ SQL Server events
Consulting & Training
Davide Mauri

4. Query Processor
Execution Plans
Data Distribution Statistics
Conclusioni
agenda

5. SQL è un linguaggio DICHIARATIVO
4° Generation Programming Language (4GL)
La query descrive il risultato che si vuole (ossia il «cosa»),
senza indicare gli step per ottenerlo (ossia il «come»)
E’ quindi necessario un engine che si preoccupi del «come»

Query Processor Overview

6. Query Processor Overview
Richiesta
SQL
Dati
(In Fretta e
Corretti)
Magi
c

7. Per ogni query inviata, il ciclo di vita è:
Query Processor
Parse Bind Optimize Execute
Qui viene definito il percorso di risoluzione della query,
o “Execution Plan”

8. Optimizer: Percorsi
• Come arrivare da «A» a «B»?
• Valuta i possibili percorsi
• E il traffico?
• E se usassi un altro mezzo?
• Da un peso a tutti i percorsi
• Prende quello meno costoso

9. Query Optimization e Complessità
Select o_year,
sum(case
when nation = 'BRAZIL' then volume
else 0
end) / sum(volume)
from
(
select YEAR(O_ORDERDATE) as o_year,
L_EXTENDEDPRICE * (1 - L_DISCOUNT) as volume,
n2.N_NAME as nation
from PART, SUPPLIER, LINEITEM, ORDERS, CUSTOMER, NATION n1,
NATION n2, REGION
where
P_PARTKEY = L_PARTKEY and S_SUPPKEY = L_SUPPKEY
and L_ORDERKEY = O_ORDERKEY and O_CUSTKEY = C_CUSTKEY
and C_NATIONKEY = n1.N_NATIONKEY and n1.N_REGIONKEY = R_REGIONKEY
and R_NAME = 'AMERICA‘ and S_NATIONKEY = n2.N_NATIONKEY
and O_ORDERDATE between '1995-01-01' and '1996-12-31'
and P_TYPE = 'ECONOMY ANODIZED STEEL'
and S_ACCTBAL <= constant-1
and L_EXTENDEDPRICE <= constant-2
) as all_nations
group by o_year order by o_year
Circa 22 Milioni di piani di
esecuzioni possibili!
Query del Benchmark TPC-H

10. Enumerare piani logicamente equivalenti applicando regole
di equivalenza
Per ciascun piano cosi generato equivalenti, enumerare tutti
i piani fisici possibili
Stimare il costo di ciascuno dei piani alternativi cosi ottenuti
Eseguire il piano con il più basso costo stimato complessivo
Query Optimization – Main Steps

11. Operatori Logici
Es:JOIN
Operatori Fisici
Es:LOOP JOIN, MERGE JOIN, HASH JOIN
Query Optimization – Operatori

12. Query Optimization – Regole di riscrittura

13. Execution Plans

14. Ad ogni step del piano di esecuzione viene assegnato un costo
stimato
La somma totale è il costo totale del piano
Viene preso il piano con il costo minore
Per query complesse non vengono valutati tutti i piani
Tecniche di «potatura» vengono usate per evitare di percorrere ramificazioni ipoteticamente
non efficienti.
Come può sapere il reale costo di ogni piano?
Non può!
Necessità di stime per capire cosa ha senso fare
Cost Based Optimization

15. Estimated vs Actual
Ovviamente, è fondamentale
che la stima sia realistica
Il percorso è stimato sulla base
della quantità di dati sui cui si
deve operare

16. Estimated vs Actual
Dall’execution plan è possibile
avere informazioni su stima e
valori attuali

17. E’ necessario avere un’idea stimata dei dati con cui si andrà ad operare
Tanto più è verosimile la stima, tanto più i piani di esecuzioni saranno
ottimali
Punti delicati
Dati distribuiti in modo non omogeneo
Dipendenze e Correlazioni
Data Distribution Statistics

18. Numero di righe
Numero di righe campionate
Densità dei dati
Totale
Per prefisso
Data ed Ora di campionamento
Lunghezza media della chiave
Numero di step (fino a 200)
Data Distribution Statistics

19. Creazione Manuale
Statistiche create automaticamente sulle colonne indicizzate
Statistiche create automaticamente da SQL Server anche
per le colonne non indicizzate
Data Distribution Statistics

20. Memorizzano informazioni sulla distribuzione dei dati
all’interno della colonna
Solo per la 1° colonna
Limitati a 200 steps
Histograms

21. Da SQL Server 2005
SYS.STATS, SYS.STATS_COLUMNS, STAT_DATE
DBCC SHOW_STATISTICS
Da SQL Server 2008 SP2 e SQL Server 2012 SP1
SYS.DM_DB_STATS_PROPERTIES
Visualizzazione ed Analisi

22. Show Statistics
HEADER
DENSITY VECTOR
HISTOGRAM
123 «Alexander»
28 Rows tra «Adams» e «Alexander» (limiti esclusi)
- 15 Valori Distinti
- 1,86 Righe per ogni valore

23. demo
Data Distribution
Statistics At Work

24. Ogni cosa che va a deteriorare la qualità delle stime è da evitare
Evitare di applicare funzioni sulle colonne nei predicati di ricerca
quando possibile
Attenzione a catene di join lunghe perché amplificano l’errore
statistico
L’utilizzo di una tabella temporanea di «appoggio» può essere di grande aiuto
Query Analysis & Optimization

25. Sapere leggere ed analizzare
Piani di Esecuzione
Statistiche
E’ fondamentale per capire e quindi ottimizare una query
Conclusioni

26. Grazie a tutti per la partecipazione
Riceverete il link per il download a slide e demo via email nei
prossimi giorni
Per contattarmi
dmauri@solidq.com
Grazie