Query Processor & Statistics: A Performance Primer

401 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
401
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Usare la mappa per arrivare da Milano a Roma.
  • Query Processor & Statistics: A Performance Primer

    1. 1. Template designed byQuery Processor & StatisticsDavide Mauridmauri@solidq.comwww.davidemauri.it
    2. 2. brought to you by
    3. 3. Works with SQL Server from 6.5, on BI from 2003Specialized in Data Solution Architecture, Database Design,Performance Tuning, BIMicrosoft SQL Server MVPPresident of UGISS (Italian SQL Server UG)Mentor @ SolidQRegular Speaker @ SQL Server eventsConsulting & TrainingDavide Mauri
    4. 4. Query ProcessorExecution PlansData Distribution StatisticsConclusioniagenda
    5. 5. SQL è un linguaggio DICHIARATIVO4° 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. 6. Query Processor OverviewRichiestaSQLDati(In Fretta eCorretti)Magic
    7. 7. Per ogni query inviata, il ciclo di vita è:Query ProcessorParse Bind Optimize ExecuteQui viene definito il percorso di risoluzione della query,o “Execution Plan”
    8. 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. 9. Query Optimization e ComplessitàSelect o_year,sum(casewhen nation = BRAZIL then volumeelse 0end) / sum(volume)from(select YEAR(O_ORDERDATE) as o_year,L_EXTENDEDPRICE * (1 - L_DISCOUNT) as volume,n2.N_NAME as nationfrom PART, SUPPLIER, LINEITEM, ORDERS, CUSTOMER, NATION n1,NATION n2, REGIONwhereP_PARTKEY = L_PARTKEY and S_SUPPKEY = L_SUPPKEYand L_ORDERKEY = O_ORDERKEY and O_CUSTKEY = C_CUSTKEYand C_NATIONKEY = n1.N_NATIONKEY and n1.N_REGIONKEY = R_REGIONKEYand R_NAME = AMERICA‘ and S_NATIONKEY = n2.N_NATIONKEYand O_ORDERDATE between 1995-01-01 and 1996-12-31and P_TYPE = ECONOMY ANODIZED STEELand S_ACCTBAL <= constant-1and L_EXTENDEDPRICE <= constant-2) as all_nationsgroup by o_year order by o_yearCirca 22 Milioni di piani diesecuzioni possibili!Query del Benchmark TPC-H
    10. 10. Enumerare piani logicamente equivalenti applicando regoledi equivalenzaPer ciascun piano cosi generato equivalenti, enumerare tuttii piani fisici possibiliStimare il costo di ciascuno dei piani alternativi cosi ottenutiEseguire il piano con il più basso costo stimato complessivoQuery Optimization – Main Steps
    11. 11. Operatori LogiciEs:JOINOperatori FisiciEs:LOOP JOIN, MERGE JOIN, HASH JOINQuery Optimization – Operatori
    12. 12. Query Optimization – Regole di riscrittura
    13. 13. Execution Plans
    14. 14. Ad ogni step del piano di esecuzione viene assegnato un costostimatoLa somma totale è il costo totale del pianoViene preso il piano con il costo minorePer query complesse non vengono valutati tutti i pianiTecniche di «potatura» vengono usate per evitare di percorrere ramificazioni ipoteticamentenon efficienti.Come può sapere il reale costo di ogni piano?Non può!Necessità di stime per capire cosa ha senso fareCost Based Optimization
    15. 15. Estimated vs ActualOvviamente, è fondamentaleche la stima sia realisticaIl percorso è stimato sulla basedella quantità di dati sui cui sideve operare
    16. 16. Estimated vs ActualDall’execution plan è possibileavere informazioni su stima evalori attuali
    17. 17. E’ necessario avere un’idea stimata dei dati con cui si andrà ad operareTanto più è verosimile la stima, tanto più i piani di esecuzioni sarannoottimaliPunti delicatiDati distribuiti in modo non omogeneoDipendenze e CorrelazioniData Distribution Statistics
    18. 18. Numero di righeNumero di righe campionateDensità dei datiTotalePer prefissoData ed Ora di campionamentoLunghezza media della chiaveNumero di step (fino a 200)Data Distribution Statistics
    19. 19. Creazione ManualeStatistiche create automaticamente sulle colonne indicizzateStatistiche create automaticamente da SQL Server ancheper le colonne non indicizzateData Distribution Statistics
    20. 20. Memorizzano informazioni sulla distribuzione dei datiall’interno della colonnaSolo per la 1° colonnaLimitati a 200 stepsHistograms
    21. 21. Da SQL Server 2005SYS.STATS, SYS.STATS_COLUMNS, STAT_DATEDBCC SHOW_STATISTICSDa SQL Server 2008 SP2 e SQL Server 2012 SP1SYS.DM_DB_STATS_PROPERTIESVisualizzazione ed Analisi
    22. 22. Show StatisticsHEADERDENSITY VECTORHISTOGRAM123 «Alexander»28 Rows tra «Adams» e «Alexander» (limiti esclusi)- 15 Valori Distinti- 1,86 Righe per ogni valore
    23. 23. demoData DistributionStatistics At Work
    24. 24. Ogni cosa che va a deteriorare la qualità delle stime è da evitareEvitare di applicare funzioni sulle colonne nei predicati di ricercaquando possibileAttenzione a catene di join lunghe perché amplificano l’errorestatisticoL’utilizzo di una tabella temporanea di «appoggio» può essere di grande aiutoQuery Analysis & Optimization
    25. 25. Sapere leggere ed analizzarePiani di EsecuzioneStatisticheE’ fondamentale per capire e quindi ottimizare una queryConclusioni
    26. 26. Grazie a tutti per la partecipazioneRiceverete il link per il download a slide e demo via email neiprossimi giorniPer contattarmidmauri@solidq.comGrazie

    ×