SQL Server Kvantitetsprestandaanalys #1
Förord
SQL Serverns kostnadsformler för exekveringsplaner, samt den egentliga kostnaden för grundläggande SQL operationer, är utforskade. Tillsammans med statistik så kan man med planens kostnadsformler avgöra vilken som är den bästa exekveringsplanen. Vilken exekveringsplan är inte bara baserat på Indexen, utan även på mängden och distributionen av data. På grund av det så kan en exekveringsplan från en produktionsmiljö skilja sig lite från en oanvänd databas. Genom att veta kostnaden för en plan så kan man förutse den använda databasens exekveringsplan. Och med de egentliga kostandsformlerna så kan man förutse prestandan från en databasapplikation som baseras på schemat, SQL-satser samt den förväntade datadistributionen.
Innehåll
»»
»
Relaterade artiklar
» SQL Server Kvantitetsprestandaanalys #2» SQL Server Kvantitetsprestandaanalys #3
» SQL Server Kvantitetsprestandaanalys #4
» SQL Server Kvantitetsprestandaanalys #5
SQL Server Kvantitetsprestandaanalys #1
av Joe Chang
Förord
Den här artikelserien är fortfarande under produktion. Läsarna är tillåtna att skicka frågor och kommentarer till författaren
Målgrupp
Den här artikelserien är avsedd för databasarkitekter samt utvecklare, som måste kunna förutse en applikations prestanda i ett tidigt stadie av utvecklingen. På så sätt så kan de möta kraven från prestanda genom att minimera senare omstruktureringar och omskrivningar. De metoder man tillgår för att optimera prestanda är enligt standard vanligast då databasens produktionsmiljö är åtkomligt. Men informationen här kan också vara användbart för databasadministratörer som har särskilt ovanliga prestandaproblem, vilka motstår hårda tag med hårdvaran eller konventionella Indexoptimeringar.
Framåt
Syftet med den här artikelserien är att etablera en kvantitetssmodell, vilken kan användas till att förutse SQL Serverns prestanda. Varje applikation kan karaktäriseras av en grupp SQL-satser, och varje sats kan ha en eller flera möjliga exekveringsplaner. En exekveringsplan består av komponentoperationer och kostnaden för varje komponentoperation beror ett antal faktorer, inklusive hur många poster som är involverade. Din Query Optimizer väljer den exekveringsplan som ”kostar” mindre eller den som har den snabbaste exekveringstiden, beroende på hur många poster som den har uppskattat samt kostnadsstrukturen för komponentoperationerna. Gruppen med de karaktäristiska satserna kommer från applikationen samt dess användning. Så en kvantitetsprestandamodell börjar med insikten om hur den optimala exekveringsplanen väljs ut. De kostformler som finns i SQL Serverns exekveringsplan kommer att diskuteras närmare lite senare i artikelserien. Exekveringsplanens kostformler representerar inte alltid den egentliga kostnaden för satsen, utan den egentliga kostnaden för grundläggande satser måste istället mätas. Dessutom adresseras de förväntade behoven från processorn och plattformen.
En undersökning av den aktuella uppmätta kostnaden av grundläggande SQL-satser visar var sats- och låsningslösningar ska sättas in för att tjäna lite prestanda i både Merge och Hash Joins. De mer konsekventa implikationerna gällande databasarkitekturen, tabellstrukturen, SQL-satserna samt Indexen, är att de måste skapas tillsammans och inte var för sig.
Fokusen i den artikelserien ligger i kvantitetsanalyser istället för sådana som är kvalitativa eller naturligt beskrivna. Det här kräver ett enormt användande av data och formler, och det är ingen lätt uppgift att förfoga över så mycket information. Fördelarna med att använda kvantitetsmodeller är att vi från exekveringsplanen och posträkningen kan se vilka SQL-satser som troligast kommer att orsaka prestandaproblem, istället för att se det genom enbart intensiva tester.
Så här långt så har prestanda- och kostnadsmätningarna utförts på endast en typ av SQL-sats i taget. Det finns ingen garanti på att dessa resultat kan utökas till produktionsmiljöer där många SQL-satser körs simultant. De resultat som hittills har samlats ihop anses dock fortfarande vara tillräckligt användbara. Man kan argumentera om hur det kaotiska i en produktionsmiljö gör det svårt att förutse prestanda. Som tur är så bör inte en företagssituation med ett enormt databasprojekt tänka på på huruvida prestandan kommer att bli 1 000 SQL-satser i sekunden eller 990 per sekund, men det kan hänga på skillnaden mellan 1 000 och 100. Även en ordning av konsekvensuppskattning gör kvantitetsmodellen användbar. Någon information är bättre än ingen information fram tills utvecklarfonden är spenderad.
Artikelserien kommer att fortsätta med följande artiklar:
1. Introduktion
- Tjänster, verktyg och script som hjälper dig granska kostnaden av en exekveringsplan.
2. Kostnader av SQL Server exekveringsplan
- Kostformler som används av SQL Server för att granska kostnaden för en SQL-sats. Del I: Indexsökningar, Bookmark Lookup, Tabellscans. Del II: Loop, Hash och Mere JOINs. Del III: INSERT, UPDATE och DELETE.
3. Definitioner och övningar av mätningar
- Kostnadsdefinitioner, processor- och plattformsbehov, villkor för körtid (Runtime), testprogram och script för datapopulation.
4. Kostnader för SELECT satser
- De uppmätta kostnaderna för grundläggande SELECT satser på en Pentium III, Pentium III Xeon och (Pentium IV) Xeon Serverplattform.
5. Kostnader för INSERT-, UPDATE- och DELETE-satser (ännu ej tillgänglig)
- Uppmätta kostnader för grundläggande INSERT-, UPDATE- och DELETE-satser på Serverplattformer i jämförelse med exekveringsplansformelns kostnader.
6. Prestandakalkyleringar (ännu ej tillgänglig)
- En kort diskussion om hu man kalkylerar databasprestandan.
7. Blandade teman (ännu ej tillgänglig)
- Användbara ting som inte har passat inte i helheten av något annat.
8. Databasarkitektur och designstrategier (ännu ej tillgänglig)
- Innebörden från exekveringsplanens kostnadsformler, statistik och den faktiska kostnaden för SQL-satser på databasarkitektur och design, samt Indexoptimering och SQL-sats hints.
0 Kommentarer