Your SlideShare is downloading. ×
0
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Query Processor & Statistics: A Performance Primer
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Query Processor & Statistics: A Performance Primer

194

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 …

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
194
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Usare la mappa per arrivare da Milano a Roma.
  • Transcript

    • 1. Template designed byQuery Processor & StatisticsDavide Mauridmauri@solidq.comwww.davidemauri.it
    • 2. brought to you by
    • 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. Query ProcessorExecution PlansData Distribution StatisticsConclusioniagenda
    • 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. Query Processor OverviewRichiestaSQLDati(In Fretta eCorretti)Magic
    • 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. 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(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. 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. Operatori LogiciEs:JOINOperatori FisiciEs:LOOP JOIN, MERGE JOIN, HASH JOINQuery Optimization – Operatori
    • 12. Query Optimization – Regole di riscrittura
    • 13. Execution Plans
    • 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. Estimated vs ActualOvviamente, è fondamentaleche la stima sia realisticaIl percorso è stimato sulla basedella quantità di dati sui cui sideve operare
    • 16. Estimated vs ActualDall’execution plan è possibileavere informazioni su stima evalori attuali
    • 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. 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. Creazione ManualeStatistiche create automaticamente sulle colonne indicizzateStatistiche create automaticamente da SQL Server ancheper le colonne non indicizzateData Distribution Statistics
    • 20. Memorizzano informazioni sulla distribuzione dei datiall’interno della colonnaSolo per la 1° colonnaLimitati a 200 stepsHistograms
    • 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. Show StatisticsHEADERDENSITY VECTORHISTOGRAM123 «Alexander»28 Rows tra «Adams» e «Alexander» (limiti esclusi)- 15 Valori Distinti- 1,86 Righe per ogni valore
    • 23. demoData DistributionStatistics At Work
    • 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. Sapere leggere ed analizzarePiani di EsecuzioneStatisticheE’ fondamentale per capire e quindi ottimizare una queryConclusioni
    • 26. Grazie a tutti per la partecipazioneRiceverete il link per il download a slide e demo via email neiprossimi giorniPer contattarmidmauri@solidq.comGrazie

    ×