Wenobi är ett skånskt konsultföretag specialiserat på Business Intelligence, dvs beslutsstöd. Jag arbetar främst som Oracle DBA, men även som

Transkript

1 Wenobi är ett skånskt konsultföretag specialiserat på Business Intelligence, dvs beslutsstöd. Jag arbetar främst som Oracle DBA, men även som modellerare och arkitekt. 1

2 Presentationen täcker Oracle-databasen 10gR2 samt några av nyheterna i 11g. Presentationen tar inte upp metoder för tuning detta finns beskrivet i massor av böcker - utan på vad som erfarenhetsmässigt lönar sig i ett datalager med Oracle. Fastna ej i detaljerna de finns nerskrivna i materialet! Här är och där finns Fördjupnings -avsnitt som pga tidsbrist inte tas upp under presentationen läs igenom dem själv efteråt om du vill! 2

3 Presentationen består av sex olika delar. Den första delen svarar på frågan Vad är ett datalager?. Här ges en kort introduktion för att ge bättre förståelse för det som följer. En vanlig datalager-arkitekturer beskrivs, liksom vanliga datamodeller samt nycklar i databasen. Slutligen beskrivs egenskaperna för databasen(erna) i ett datalager, vilket sätter scenen för prestanda-optimeringen. 3

4 I del två beskrivs olika komponenter för bra prestanda som är genellera, dvs de gäller såväl ETL som OLAP (som beskrivs närmare senare). De består av: Tabelldesign Partitionering Indexering Parallelism Optimeraren Advisors SQL 4

5 Del tre behandlar prestanda för transformeringen och laddningen (ETL står för Extract, Transform Load, där extraheringen görs i källsystemen som inte beskrivs i denna presentation) av datalagret. De olika komponenterna här består av: SQL PEL Constraints Sekvenser Del fyra behandlar prestanda för OLAP (slutanvändar-queries). De olika komponenterna här består av: SQL Materialiserade vyer 5

6 Den femte delen behandlar kompromisser för ETL OLAP-prestanda, dvs när bättre ETL-prestanda leder till sämre OLAP-prestanda och vice versa, samt vad man kan göra i sådana lägen. Den sista delen presenterar receptet, som är en lathund för bra datalager-prestanda, dvs en sammanfattningen av presentationen. 6

7 Detta avsnitt är en kort introduktion till datalager-konceptet. 7

8 Ett datalager är en stor databas(er), med omgivande verktyg, som används av användare som vill analysera företagets verksamhet för att förstå vad kunderna vill ha, hur de vill ha det, när de vill ha det, etc, för att göra företaget bättre (och därmed tjäna mer pengar). Databasen innehåller all relevant data för analysen, som samlas in från diverse källsystem inom (och utanför) företaget. De klassiska egenskaperna för ett datalager låter såhär på engelska: Subject oriented (dvs det berör olika analysområden som försäljning eller logistik), integrated (data integreras från flera källsystem), nonvolatile (data ändras normalt inte när det väl laddats), time variant (analyserna kan göras för olika tidpunkter i datat). Databasen(erna) används för slutanvändar-queries på stora mängder data (OLAP, On- Line Analytic Processing). Dessa datamängder måste först laddas med hjälp av ETLprocessen (Extract, Transform, Load). Detta i motsats till OLTP (On-Line Transaction Processing), som består av många korta transaktioner. 8

9 Det finns olika datalagerarkitekturer, en av de viktigaste kan man kalla för datalager med EDW (Enterprise Data Warehouse). Bilden visar den första varianten med ett EDW i mitten (Warehouse), som innehåller all integrerad och transformerad data på lägsta nivån (raw data). Detta data laddas från diverse källsystem (Data Sources) till EDW via en mellanarea (Staging Area). Även aggregerad data kan finnas (summary data), liksom data om datat (metadata). EDWdatat laddas sedan till flera olika data marts (för olika analysområden). På så vis behövs logiken för att transformera källdatat till EDWt bara en gång, och man garanterar att de olika data martsen hänger ihop med varandra (som de korsande pilarna visar). Data marts kan bestå av tabeller i databasen som accessas direkt av användarnas OLAP-verktyg, eller tabeller som laddar OLAP-kuber (detta syns ej på bilden) som sedan används av ett OLAP-verktyg. Fördjupning Den andra arkitektur-varianten saknar EDW, laddningen av data marts sker direkt från Staging Area. Även här hänger de ihop med varandra. Vilken lösning man väljer, eller en hybrid, är en religiös fråga och en annan kurs! OLAP-kuber innehåller data i ett speciellt format. En OLAP-kub kan finnas i en fil i OLAP-verktyget eller direkt i databasen (OLAP option), som sedan accessas av OLAP-verktyget. Man kan även ladda OLAP-kuber direkt från EDWt. 9

10 Två olika datamodeller förekommer i datalager: Normaliserad modell och stjärnschema. Vilken man väljer (eller bägge) är en annan religiös fråga bägge varianterna beskrivs i presentationen. En normaliserad modell används ofta i ett EDW. Normaliserad är en sanning med modifikation jag återkommer till det. Ett stjärnschema (se bilden) används ofta i data marts, eftersom det är lätt att förstå för användarna. OLAP-kuber har en struktur liknande stjärnschemats. Flera stjärnscheman (eller OLAP-kuber) kan finnas i en data mart. Tabellen i mitten, faktatabellen, innehåller fakta, dvs siffror (i det här fallet om försäljning). Tabellerna runt omkring kallas dimensioner och innehåller diverse attribut om siffrorna (vilka är produkterna som säljs, när såldes de, vilka kunder köpte dem, vilka säljkanaler användes vid försäljningen). En faktatabell är oftast historisk, dvs nya poster som kommer in gäller för nya datum. Varje post i faktatabellen har främmande nycklar (FKs) mot dimensionstabellerna (faktatabellens primärnyckel är samtliga dessa FKs konkatenerade). Varje dimension kan bestå av en (eller flera) hierarkier med ett antal nivåer i varje. För tidsdimensionen kan man ha en hierarki med nivåerna dag, vecka och år. När en slutanvändare ställer en SQL-fråga mot stjärnschemat, består den av en join mellan faktatabellen och dimensionerna, med WHERE på kolumner i dimensionstabellerna. Användaren utgår alltså från dimensionerna för att ställa frågan, medan faktatabellen ger svaret. 10

11 I datalagrets databas(er) finns data från flera olika källsystem. Olika källsystem har olika nycklar i sina tabeller, så kallade naturliga nycklar, men varje tabell i databasen kan bara ha en primärnyckel. Därför har de flesta tabellerna i datalagret en surrogatnyckel, en konstgjord nyckel, som brukar implementeras som en sekvens (dvs ett NUMBER-fält). Detta innebär, förutom oberoende av källsystem, även att joins mellan olika tabeller kan ske snabbare med de enkla surrogatnycklarna istället för multipla fält (de naturliga nycklarna). De naturliga nycklarna måste naturligtvis finnas med i datalagret, så att nya källposter kan uppdatera eller skapa nya poster i datalagret på rätt sätt. De naturliga nycklarna kan antingen finnas i samma tabeller som datat med surrogatnycklarna, eller i speciella lookup-tabeller. 11

12 Databasen(erna) i ett datalager har följande egenskaper: Stora mängder data (TB och uppåt), ständigt växande Snabb ETL Ännu snabbare dataåtkomst (OLAP), ständigt fler användare Presentationen kommer att ge prestandatips generellt, specifikt för ETL och specifikt för OLAP. 12

13 Detta avsnitt behandlar metoder för bra prestanda som gäller såväl ETL som OLAP. 13

14 Följande kan göras i tabelldesignen för att ge bättre prestanda: Denormalisering Som redan nämnts, görs viss denormalisering för att minska antalet joins när tabellerna läses (för såväl normaliserad modell som stjärnschema). En tabell för orderhuvud i ett EDW kan exempelvis innehålla ett fält för orderdatum, som även finns i orderrad-tabellen. När orderrad-tabellen läses för att ladda data marts, behövs kanske enbart orderdatumet som rent logiskt finns i norderhuvudet, vars tabell då inte alls behöver läsas. Denormalisering innebär dock mera komplex ETL (eftersom även de redundanta fälten måste underhållas) samt mera diskutrymme. En annan variant är att orderhuvudstabellen inte finns alls, utan bara en sammanslagen sådan med orderhuvuds- och orderrads-data. Fördjupning PCTFREE är det utrymme i ett block som Oracle inte fyller när poster skapas i blocket, för att försöka ge utrymme för UPDATEs senare utan att blocket blir fyllt (och måste splittras, vilket tar extra lång tid). I ett datalager görs ofta bara INSERT i de stora faktatabellerna. Använd då ett lågt värde på PTCFREE för att minska storleken på stora tabeller, t.ex. 1% (default är 10%). Detta gör tabellen 9% mindre (och därmed 9% snabbare att använda). 14

15 Komprimering Komprimering minskar typiskt tabellens storlek till mellan en tredjedel och hälften (mina egna siffror ligger mellan 2.5 och 2.8) => snabbare full table scan och backup, och mindre disk går åt. Komprimering fungerar bara för direct load INSERT (se SQL i avsnittet Prestanda för ETL ). Komprimering ger alltså snabbare SELECT, men kan ge långsammare INSERT och ännu långsammare UPDATE/MERGE eftersom komprimeringen tar tid. 11g: Fungerar för all DML (även vanlig INSERT samt UPDATE/MERGE). Dessutom är komprimeringsalgoritmen snabbare. 15

16 Vad är partitionering? Partitionering innebär att en tabell delas upp fysiskt i flera, så att olika poster lagras i olika fysiska tabeller (partitioner). SQL mot tabellen behöver dock inte känna till uppdelningen, utan ser en vanlig tabell. Uppdelningen i partitioner sker med hjälp av en (eller flera) kolumner i tabellen, ofta en tidskolumn, så att poster för olika datum (eller veckor, år etc) hamnar i olika partitioner. Fördjupning Vi talar egentligen om horisontell partitionering. Konceptuellt finns även vertikal partitionering, dvs olika kolumner i en tabell lagras i olika partitioner. Vertikal partitionering finns dock inte implementerat i Oracle (möjligen kan man hävda att IOT, Index-Organized Tables, är en enkel form av vertikal partitionering), i resten av presentationen innebär begreppet partitionering alltid horisontell partitionering. 16

17 Varför partitionera? Partitionering ger Partition pruning, dvs endast de partitioner som innehåller de önskade posterna läses när tabellen läses. Detta ger snabbare SELECT, samt snabbare lookup för UPDATE/MERGE och DELETE (det sista är dock ovanligt i datalager-sammanhang). Tidspartitionering => historisk data finns i egna partitioner. Om olika tidsperioder läggs i olika tablespace, kan tablespacen (datafilerna) för gamla perioder enkelt läggas på billigare disk eller band. Alternativt kan partitionerna enkelt tas bort när de är för gamla för att vara intressanta. Detta kan även kombineras med komprimering, eftersom gammal data sällan uppdateras. Manuella skript och DBA-underhåll (SHRINK etc) kan köras på en partition i taget. Om recovery behöver göras och partitionerna finns i olika tablespace, kan de viktigaste (mest använda) partitionerna läsas tillbaka först, så att användarna snabbare kan utnyttja datalagret igen. 17

18 Det finns ett antal typer av partitionering (se bilden): Range Poster där partitioneringskolumnen är mindre än ett visst värde, och större än värdet i den förra partitionen, hamnar i samma partition. Range-partitionering är bra stora datamängder (som faktatabeller). List Posterna i en partition har ett eller flera diskreta värden på partitioneringskolumnen (som bara kan bara vara en). List-partitionering är bra för stora ohistoriska tabeller (t.ex. i dimensionstabeller på region eller ordertyp). Hash En formel appliceras på partitionskolumnen, som ger numret på partitionen där posten ska lagras (t.ex. ett tal mellan 1 och 64). Formeln är tänkt att sprida ut posterna så jämnt som möjligt till alla partitionerna. Hash-partitionering (t.ex. på artikelnummer) är bra När annan partitionering hade givit skev fördelning av data i de olika partitionerna, och man kan dra nytta av olika partitioner på olika diskar eller När exekveringsplanen visar en NESTED LOOP där den aktuella tabellen läses för varje varv i lopen => partition pruning snabbar upp (jag har här sett exempel på exekveringstider som minskat till mindre är en tiondel) 18

19 Komposit Detta är helt enkelt en kombination av range, list och hash-partitionering. Partition pruning på en komposit-partitionerad tabell fungerar på såväl huvudpartitionerna som på subpartitionerna var och en för sig. De olika kombinationerna som är implementerade i Oracle är: Range hash (för mycket stora faktatabeller) Range list (för mycket stora faktatabeller) 11g: Range range 11g: List range 11g: List list 11g: List hash 11g: Intervall-partitionering: Detta är range-partitionering där Oracle automatiskt skapar nya tidspartitioner efter hand, i 10g måste man göra detta manuellt. Fördjupning Partition-wise joins används ofta i kombination med hash-partitionering och parallelism (som beskrivs närmare i avsnittet Parallelism ): Tabellerna man vill joina är partitionerade på join-nyckeln. Varje producer-slav läser en partition. Producern skickar resultatet till motsvarande consumer-slav (consumer-slavarna har tidigare läst den motsvarande partitioner i den andra tabellen), istället för till alla. Detta sparar minne (för slavarnas buffer cache, vilket också kan minska eller undvika TEMPanvändning) och CPU. 19

20 Partition pruning görs tyvärr ej alltid även om det är teoretiskt möjligt, så hur vet man att partition pruning fungerar? Jo, kontrollera PSTART (PARTITION_START) och PSTOP (PARTITION_STOP) i exekveringsplanen. Statisk partition pruning (se bilden): Optimeraren utnyttjar konstant(er) i SQLkoden som ger partitionen(erna) PSTART och PSTOP direkt med siffror. Detta ger partition pruning, där bara de(n) angivna partitionen(erna) läses. Detta är bra! Dynamisk partition pruning: Partitionsnyckelns värden nås via en join, eller bindvariabler används istället för konstanter i SQL-koden. Detta ger KEY i PSTART och/eller PSTOP. Nu är det upp till Oracle... Kontrollera exekveringsplanen, och försök se om partitionsnyckeln tas fram innan den partitionerade tabellen läses (så att värdet på KEY är beräknat då), i så fall får man partition pruning. Optimeraren ska ta rätt beslut för att möjliggöra partition pruning, men i praktiken fungerar det ibland dåligt när inga direkta konstanter finns. Det verkar i det läget ibland som om optimeraren skapar en exekveringsplan som om alla tabeller var opartitionerade, sedan lägger den in partitioneringsvillkoren (PSTART och PSTOP) och så får man partition pruning om man har tur... På följande slides visas hur man kan se om dynamisk partition pruning fungerar, utan att man behöver gräva i exekveringsplanen. 20

21 Hur vet man att dynamisk partition pruning verkligen fungerar, om man inte är säker på att exekveringsplanen gör saker och ting i rätt ordning? Jo, man köra SQL-koden efter att ha tracat event Innan detta görs, måste man skapa tabellen KKPAP_PRUNING så att det är tillgängligt i schemat där man kör SQL-koden. Den ser ut som på bilden. 21

22 Event tracas sedan genom kodsnutten som visas ovan. Därefter kör man SQLkoden man vill testa, se exemplet ovan. Faktatabellen sales är partitionerad på year, med 5 partitioner (som i trace-filen kommer att vara numrerade från 0 till 4, där 0 är år 2006, 1 är år 2007 osv till 4 som är år 2010). I SQL-koden finns ett villkor att åren före och lika med nuvarande år ska läsas. Detta villkor är skrivet som en sub-query, som plockar fram det nuvarande året ur tabellen day_dt. 22

23 Trace-filen hamnar i den vanliga udump-katalogen på servern. Här kan man se följande (se bilden): Först parsas SQL-koden (call time = COMPILE). Eftersom year inte är en konstant, genereras exekveringsplanen för samtliga partitioner (iterator = RANGE [0, 4]). Under runtime (call time = START) kontrolleras dynamisk vilka partitioner som behöver accessas. Eftersom subqueryn exekveras före den partitionerade tabellen, vet optimeraren att det sista året är 2008 (dvs partition 2 i iterator = RANGE [0, 2]). Här fungerar alltså dynamisk partition pruning. 23

24 Sammanfattningsvis är partitionering (nästan) gratis rent tekniskt (det ger en aning overhead), till skillnad från index eller materialiserade vyer (som behandlas senare). Det ger antingen (mycket) bättre prestanda eller ingen skillnad, och har dessutom alltid de andra fördelarna. Dock kostar licensen för partitionering extra... 24

25 Indexering är nästa punkt på agendan. Följande typer är de vanligast förekommande: Normala index (B-tree), för normaliserad modell och stjärnscheman Bitmap-index, oftast för stjärnscheman Bitmap join-index, oftast för stjärnscheman De återstående indextyperna (som function-based index) tas inte upp här. När ska index användas? Ett index gör bara nytta när en tillräckligt liten del av posterna i tabellen läses med hjälp av indexet. I ett datalager läses ofta alla poster i en tabell (eller partition) index gör då ingen nytta eftersom det skulle ta ännu längre tid att läsa det också. Index i datalager behövs typiskt för: Lookuper (ofta på naturlig nyckel), i laddning av EDW eller data marts Slutanvändarqueries med WHERE-villkor (såväl bitmap som normala index) När ska normala index användas? Jo, när antalet olika indexkolumnvärden är högt, vilket gäller för unika nycklar (exempelvis naturliga nycklar). 25

26 När ska bitmap-index användas? Jo, när antalet olika indexkolumnvärden är lågt (tvärtemot normala index alltså) i förhållande till antalet poster i tabellen. Ett bitmap-index är konstruerat så att för varje värde på den indexerade kolumnen finns en struktur med lika många bitar som poster i tabellen, där varje bit med hjälp av en formel ger ett rowid (den exakta fysiska platsen på disk) för tabellposten. Om biten = 1 innebär det posten har värdet på kolumnen. I bilden ovan visas två bitmap-index, ett för fältet STATUS (som bland annat kan ha värdet married ) och ett för fältet REGION (som bland annat kan ha värdena central och west. En SQL-fråga med ett WHERE-villkor STATUS = MARRIED AND (REGION = central OR REGION = west ) kommer då att utnyttja de två bitmap-indexen för att för varje post i tabellen beräkna 1 (posten finns) eller 0 (posten finns inte), som syns längst till höger i bilden. Fördjupning Ett bitmap-index tar liten plats. I tidigare Oracle-versioner ökade storleken (och laddningstiden) när många poster i dess tabell skapades eller uppdaterades (som i ETL-processen), men numera är detta inte ett lika stort problem. Ett bitmap-index innehåller NULL-värden (i motsats till normala index), vilket kan vara bra för OLAP-queries. I datalager behöver lågt antal indexkolumnvärden inte vara så lite som man kanske tror... En idé är att testa bitmap-index för varje icke-unik kolumn man vill indexera. 26

27 När ska bitmap join-index användas? Ett bitmap join-index skapas på en kolumn (attribut) i dimensionstabellen, genom en join mellan primärnyckeln (PK) i dimensionstabellen och en främmande nyckel (FK) i faktatabellen => joinen mellan dimensionstabellen och faktatabellen behöver ej göras. Indexet tar mycket mindre plats än motsvarande materialiserad vy (se Materialiserade vyer i Prestanda för OLAP ). Star transformation En speciell form av optimering, mycket användbar vid OLAP-queries, kallas star transformation, vilket förutsätter bitmap-index på varje kolumn i faktatabellen som joinas med dimensionstabeller (dvs alla FK-kolumner). Datat kommer då att läsas på följande sätt: 1. Dimensionstabellerna läses med de WHERE-villkor OLAP-queryn har (kanske med hjälpav andra bitmap-index utnyttjas), vilket ger värden på FK-kolumnerna (dvs bitmapindex-strukturerna) i faktatabellen. 2. Oracle utför AND-operationer mellan bitmap-indexen (FK-kolumnerna) för att hitta de matchande faktaposterna. 3. Faktaposterna joinas med dimensionerna för att ge de önskade dimensionsattributen. Fördjupning Star transformation fungerar även för bitmap join-index (som då är definierat på en dimensionkolumn joinat mot faktatabellen). Om WHERE-villkoret görs på indexkolumnen slipper man därmed steg 1 i algoritmen. 27

28 Index i partitionerade tabeller Det finns tre olika huvudvarianter av index i partitionerade tabeller: 1. Lokala index: Indexet är partitionerat på samma kolumn(er) som tabellen, dvs varje index-partition motsvarar en tabell-partition. När partition pruning fungerar på tabellen kommer det följaktligen att fungera även på indexet, som därmed blir snabbare att använda. Fördelarna med lokala index är i princip de samma som för partitionerade tabeller. Dessutom: När en partition i tabellen laddas, behöver endast motsvarande indexpartition uppdateras. Om ett lookup-index (som ofta är en unik nyckel) används i ETL-processen för en partitionerad tabell, är det av denna anledning synnerligen lämpligt att indexet är lokalt och att partitioneringsnyckeln är en av kolumnerna. Fördjupning Det finns två olika varianter på lokala index: Prefixed: Partitioneringskolumnen(erna) är de vänstraste av indexkolumnerna => ett WHERE-villkor på index-kolumnen(erna) medför partition pruning för indexet (och därmed tabellen). Non-prefixed: Annars. Samtliga partitioner i indexet måste läsas för ett WHERE-villkor på indexkolumnen(erna). Å andra sidan kan ju SQL-koden innehålla WHERE för både partitioneringskolumnen och indexkolumnen, då får man partition pruning för indexet. 28

29 Index i partitionerade tabeller, forts 2. Globala index (som alltid är prefixed): Indexet är partitionerat på andra kolumn(er) än tabellen, dvs posterna i en index-partition pekar på vilka tabellpartitioner som helst. Partition pruning kan alltså fungera på indexet utan att det gör det på tabellen, och vice versa. Fördelarna med globala index är i princip de samma som för partitionerade tabeller, dock måste alla index-partitioner uppdateras när en tabell-partition laddas. 3. Opartitionerade index: De fungerar precis som index i opartitionerade tabeller. Fördjupning Globala index är alltid prefixed i Oracle. Globala bitmap-index finns inte alls. 29

30 Parallelism är i princip ett måste i datalager, eftersom det är ett bra sätt att kunna skala upp prestanda efterhand som datamängden och/eller ETL-komplexiteten och/eller OLAP-accessen ökar. Fungerande parallelism kräver: Flera CPU-er, som kan utnyttjas mer Flera diskar (ofta kopplade till ett SAN), som kan utnyttjas mer Tillräckligt med minne (som behövs för slavarna, se nedan) Hur fungerar parallelism? Ett antal processer finns, en query-koordinator och ett bestämt antal slavar. Koordinatorn fördelar jobbet mellan de olika slavarna, som var och en gör en del av det. Vid partitionerade tabeller eller index jobbar varje slavarna partitionsvis. Fördjupning Två set slavar finns, producers (som läser från tabeller) och consumers (som utför join/sortering), varje set består per default av CPU_COUNT*PARALLEL_THREADS_PER_CPU (init-parametrar) stycken slavar. När de båda seten slavar gjort sitt jobb, blir consumer-slavarna producer-slavar, som så småningom ger datat vidare till de nya consumer-slavarna (för en ny join/sortering). Och så vidare enligt exekveringsplanen... Query-koordinatorn ger slutligen resultatet till klienten. Subqueries kan ge multipla grupper av producer/consumer-set, dvs det kan här bli många processer. 30

31 När ska parallelism användas? Inte alltid! Använd parallelism för Queries (SELECT) och DML (INSERT, UPDATE, MERGE, DELETE) mot stora (partitionerade) tabeller och DDL, exempelvis för att skapa stora index När är då parallelism inte bra? Jo: Parallelism med små tabeller => korta queries => overhead => oförändrad eller sämre prestanda SQL queryn kan ställa till det om den är alltför komplex (den kanske har för många subqueries => för många slavar) 31

32 Hur aktiveras parallelism? Jo, genom 1. Hintar i koden eller 2. PARALLEL på tabeller man vill exekvera mot parallellt (dvs stora) Den första varianten är i mitt tycke att föredra, eftersom den andra kommer att ge parallelism även för små skrutt-sql-er där det inte lönar sig. Med hintar går det dessutom att ange DOP (Degree Of Parallelism), dvs antalet slavar, där det optimala antalet kan variera för olika SQL mot samma tabell. Hintar förutsätter dock att SQLkoden kan ändras, vilket möjligen inte alltid är fallet med genererad SQL-kod från OLAP-verktyg. Slutligen finns även en annan typ av parallelism: Delar av ETL-processen kan innehålla SQL som exekverar parallellt. Detta kan fungera bra, men om alltför mycket kör parallellt kan CPU-er och/eller diskar slå i taket och därmed gör det ingen nytta. Ännu värre: minnet kan ta slut. Denna effekt kan bli ännu värre om ETL-parallelism kombineras med Oracle-parallelism. På samma sätt kan laddning av OLAP-kuber ske parallellt. Finns det flera data mart-slutanvändare (vilket man får hoppas!) körs även OLAP-queries parallellt. Fördjupning Om man kontrollerar kostnaden för en exekveringsplan där man lagt till en PARALLEL-hint i SQL-koden, är den alltid mindre än utan hint (seriellt). Om man ökar DOP, sjunker kostnaden ju högre DOP-värde man anger (i all oändlighet). Detta är naturligtvis inte sant, utan bara en formel som optimeraren använder sig av... 32

33 Optimeraren är den komponent i Oracle som tar fram exekveringsplaner för SQL-kod, så att exekveringen blir så snabb som möjligt. CBO I gamla versioner av Oracle skiljde man på RBO (Rule-Based Optimizer, som var den första som kom) och CBO (Cost-Based Optimizer, som kom senare). Numera är RBO nästan borta (Oracles egen kod använder den ibland lustigt nog) och CBO är det som gäller. Vitsen med CBO är att kostnaderna för de olika delarna av exekveringsplanen baseras på statistik om innehållet i de olika tabellerna. Eftersom kostnaden för att läsa alla posterna i en tabell naturligtvis ökar ju större tabellen är, kan detta ge helt andra exekveringsplaner efterhand som data fylls på. Detta är extra viktigt i datalager som innehåller mycket stora tabeller. CBO är alltså det som gäller! 33

34 Statistik Som redan nämnts, baserar CBO sitt arbete på statistik om varje tabell och index (antalet poster, fördelningen på olika kolumnvärden, mm). För att CBO ska fungera bra krävs följaktligen att statistiken är up-to-date! Även som DBA missar man ibland detta, när en query går oförklarligt långsamt... Statistik samlas per default av ett Oracle-jobb i natt/helg-fönstret (en tidsperiod under varje natt och helg), på alla stale tabeller (eller enstaka partitioner i tabellerna). En stale tabell/partition är en vars data har ändrats tillräckligt mycket sedan jobbet körde senast, där tillräckligt mycket är i storleksordning 10% nya/ändrade/borttagna poster sedan förra statistikinsamlingen. Oracle håller själv reda på hur många poster som ändrats. Stora tabeller kan ta lång tid att analysera, detta kan snabbas upp genom att exempelvis samla statistiken parallellt (detta ändras med parametrar). 34

35 Statistik, forts Temporära tabeller som töms och laddas av en ETL-kodsnutt kan ställa till problem för en annan ETL-kodsnutt som senare läser från tabellen. Om statistiken råkar samlas in efter tömningen men innan laddningen, kommer exekveringsplanen för den andra snutten att baseras på missvisande statistik (0 poster). Lösningen på problemet är att samla in statistiken i den första snutten, efter laddningen. Dessutom kan den automatiska statistikinsamlingen blockeras för tabellen, så att den inte råkar köra samtidigt som den manuella. Eftersom ETL-processen ofta sker nattetid, är det kanske inte så bra att samla in statisiken just då (pga problemet med temporära tabeller och att statistik-insamlingen kräver en del CPU och disk). Fönstret kan då flyttas till en bättre tidpunkt. Ibland kan det hända att all statistik inte hinner samlas in när fönstret är slut (då jobbet avbryts). Eftersom Oracle samlar in statistiken i en viss ordning, kan det då hända att samma tabeller inte hinns med natt efter natt. Eftersom helgfönstret är betydligt längre, kanske dessa tabeller behandlas då, men det kan också hända att de inte hinns med då heller. Kontrollera därför att statistikjobbet verkligen exekverar färdigt, om det inte går kan fönstret förlängas (eller flyttas). Om inte heller det hjälper kan statistikinsamlandet för tabellerna som tar längst tid att analysera blockeras, och får då analyseras manuellt vid någon lämplig tidpunkt. Fördjupning Samla även systemstatistik (måste göras manuellt vid belastning) för att få värden på hur snabb CPU och I/O är. Detta borde ge bättre exekveringsplaner. 35

36 Hintar Undvik hintar i SQL-koden (se exempel i bilden ovan). Även om de är optimala för queryn just nu, är de kanske inte det när datamängden förändras. Dessutom försvårar hintarna varje ny version av optimeraren (som normalt gör ett bättre jobb för varje ny version) att göra rätt. Dock finns några hintar som inte har med exekveringsplaner att göra, som jag absolut rekommenderar: APPEND (ger direct load, se SQL i Prestanda för ETL ) PARALLEL (ger parallelism, vilket på sätt och vis har med exekveringsplanen att göra) LOGGING/NOLOGGING (redo-loggar, se SQL i Prestanda för ETL ) REWRITE/NOREWRITE (query rewrite, se Materialiserade vyer i Prestanda för OLAP ) 36

37 SQL-profiler SQL-profiler är inte detsamma som outlines (lagrade exekveringsplaner), utan mer verkliga kostnader för en viss SQL-kod som ej enbart är baserade på statistik. SQLprofiler skapas av SQL Tuning Advisor (se Advisors senare) genom att SQL-koden (delvis) exekveras. När advisorn har startats mot en exekverande query, kan sessionen som körde queryn dödas. När advisorn skapat profilen, kommer queryn att utnyttja den nästa gång den körs. En SQL-profil måste matcha SQL-koden exakt, inklusive hintar. SQl-profiler kan fungera bra vid långa statiska queries när den vanliga planen blir för dålig (verkliga exempel kan minska från 10 till 2 timmars exekveringstid). De kan dock ta flera timmar att skapa. 37

38 Det finns några advisors i Oracle, som är åtkomliga från OEM (Oracle Enterprise Manager, ett Web-baserat administrationsverktyg som följer med databasen) eller som PL/SQL-paket. Följande advisors finns: SGA Advisor Denna advisor ger förslag på hur stor minnesarean SGA (som bestäms av initparametern SGA_TARGET) ska vara, baserat på statistik från databasens användning (som alltså ska vara belastad). Resultatet kombineras lämpligen med ASMM (Automatic Shared Memory Management), så att man själv slipper bestämma hur stor del av minnet som ska användas till de olika delarna buffer cache/shared pool/large pool/java pool/streams pool. Oracle justerar dynamiskt. Automatiken hanterar dock ej log buffer, buffer cache för icke-standard blockstorlek, KEEP/RECYCLE buffer cache, samt interna SGAdelar. Det verkar dock som om Oracle bara vill ha mer och mer SGA-minne hela tiden... Kontrollera även att inte någon pool i SGAn får för lite utrymme, sätt i så fall dess init-parameter (som i det här fallet fungerar som ett minimun-värde). 11g: Fler cachar hanteras automatiskt. 38

39 PGA Advisor Denna advisor ger förslag på hur stor respektive sessions-minnesarean PGA (som bestäms av init-parametern PGA_AGGREGATE_TARGET) ska vara, även här baserat på statistik från databasens användning. AGGREGATE innebär att storleken är den totala, för alla sessioners PGA. Resultatet kombineras lämpligen med Automatic PGA Memory Management, så att man själv slipper bestämma hur stor del av minnet som ska användas till sortering/hash-join/bitmap merge/direct path read buffrar. Oracle justerar dynamiskt. Även här verkar dock som om Oracle bara vill ha mer och mer PGA-minne hela tiden... Det kan hända att slavar äter upp allt minne i servern när de utför direct path read, som innebär att datat läggs i PGA istället för i buffer cache i SGA. Orsaken är att PGA_AGGREGATE_TARGET inte är ett absolut tak, utan bara ett mål. PGA kan alltså växa så mycket att minnet (även det virtuella) i servern börjar ta slut, så att operativsystemet börjar skjuta ner processer hej vilt. Inte bra alls... Sätt PGA_AGGREGATE_TARGET så att det finns lite minnesmarginal (med hänsyn till SGA, Oracle-processernas eget minne, andra applikationer på servern, samt operativsystemets egna behov). Fördjupning Får man problem med någon del av PGA-minnet kan man använda manuella parametrar (som då gäller som exakta värden, ej som minimivärden som för SGAn). 39

40 SQL Tuning Advisor Denna advisor gör följande: Rekommenderar SQL-profiler (som beskrevs i avsnittet Optimeraren ). Rekommenderar statistikinsamling om statisiken är stale. Definitionen på stale verkar ej alltid vara den samma som statisitikjobbets (konstigt nog), så det behöver inte vara något problem när dessa rekommendationer dyker upp. Rekommenderar index, men tar ej hänsyn tillkostnaden för att underhålla indexet (se SQL Access Advisor strax). Rekommenderar SQL-ändringar (sällsynt). Tyvärr ger advisorn upp vid alltför komplex SQL (efter diverse klagomål på felaktig SQL). Jag vet inte om detta är en bugg eller en feature... Rekommendationerna implementeras sedan, om man vill, med några musklick i OEM. 11g: Rekommendationerna kan implementeras automatiskt. 40

41 SQL Access Advisor Denna advisor rekommenderar index och materialiserade vyer (se Materialiserade vyer i Prestanda för OLAP ), även borttag när de inte gör tillräcklig nytta. Den tar även hänsyn till kostnaden. Rekommendationerna implementeras sedan, om man vill. 11g: Advisorn rekommenderar även partitionering, dvs vilken typ och för vilka kolumner. Snart är DBAn arbetslös... 41

42 ADDM ADDM (Automatic Database Diagnostic Monitor) körs automatiskt efter varje AWRinsamling (f.d. Statspack), som också sker automatiskt, per default en gång i timmen. AWR (Automatic Workload Repository) samlar in systemstatistik som lagras i speciella tabeller. Med hjälp av den insamlade statistiken upptäcker ADDM långsam SQL (och PL/SQL), segment (tabeller, index eller partitioner) som accessas ofta, långsam I/O, långsam CPU, för lite SGA/PGA-minne (verkar den alltid tycka!), mycket parsning eller lås, för långsam redo-loggning eller buffer cache som ej hinner skrivas på disk. ADDMs rekommendationer kan fungera bra som bas för fortsatt tuning (som är en annan kurs), hjälper de inte får man gräva ner sig i AWR-rapporten. Fördjupning ADDM kan klaga på att I/O-prestandan bara är exempelvis 0,2 MB/s. Denna siffra gäller hela intervallet (dvs normalt timmen), även om I/O inte gjorts hela tiden. Det kan alltså bli ett väldigt lågt värde, men så illa behöver det alltså inte vara. 42

43 Segment Advisor Segment Advisor körs automatiskt som ett jobb i natt/helg-fönstret (från 10gR2), samtidigt som statistikinsamlings-jobbet. Advisorn hittar oanvänt utrymme i segmenten (dvs tabeller i opartitionerade tabeller och partitioner i partitionerade), dvs tomma eller ej helt (förutom PCTFREE) fyllda block. Den hittar inte fragmenterade tablespace (extents som ej utnyttjas). Oanvänt utrymme är normalt inget stort problem i datalager eftersom DELETE sällan görs och UPDATE mest görs i dimensionstabellerna, men om hål av någon anledning (exempelvis manuell DELETE av poster följt av direct load omladdning som inte utnyttjar de borttagna posternas utrymme) uppstår i faktatabellerna kan de bli stora. Denna advisor hittar sådant utrymme, som man kan ta bort med några musklick i OEM. Kommandot som då exekveras (se bilden) behöver till skillnad från ALTER TABLE <tabell> MOVE TABLESPACE (som utförs även för att bli av med extent-fragmentering i tablespace) inte det dubbla utrymmet, och gör ej heller index invalid (som gör att de måste byggas om för att kunna användas). Precis som för statistikinsamlings-jobbet kan det hända att advisorn inte hinner exekvera färdigt under fönstret, var vaksam på detta! 43

44 Sist men absolut inte minst: Hur ska SQL-kod se ut för att ge bra prestanda? Eller, hur ska den inte se ut? Några exempel på dålig SQL-kod (som ibland beror på att ett ETL- eller OLAPverktyg används där det är lätt att skapa komplex SQL): Samma stora tabell läses flera gånger i SQL-koden, utan att det är absolut nödvändigt. WHERE-villkor för en stor tabell kommer sent i SQL-koden, dvs inte direkt i subqueryn där tabellen läses utan senare i en query utanför den som läser tabellen. Hela tabellen måste då kanske (beroende på exekveringsplanen) joinas med andra tabeller innan posterna filtreras bort. SQL som ej ger partition pruning (se avsnittet Partitionering i Prestanda generellt tidigare). En funktion används i ett WHERE-villkor på en indexerad eller partitionerad kolumn (exempelvis TO_CHAR på ett NUMBER-fält). Hela indexet måste då läsas, alternativt fungerar ej partition pruning. Tag bort funktionen och placera dess motsats (exempelvis TO_NUMBER) på andra sidan = om där finns en konstant, eller skapa ett funktionsbaserat index. Onödiga UNIONs använd UNION ALL när man vet att inga dubletter finns. Jag återkommer till SQL i avsnitten Prestanda för ETL och Prestanda för OLAP. 44

45 ETL-processen i ett datalager innebär alltså att data laddas från källsystemen, via en staging area och eventuellt ett EDW till data marts, och slutligen eventuellt till OLAPkuber (eller OLAP i databasen). Detta sker ofta en gång per dygn (på natten), så att datat är redo för slutanvändarna nästa morgon. Det finns ETL-verktyg som genererar SQL-kod, men man kan också skriva SQLkoden manuellt. Mycket DML (INSERT/UPDATE/MERGE/DELETE) görs alltså här, men eftersom laddningen sker i flera steg görs även mycket SELECT. Stora mängder data transporteras genom de olika stegen. I detta avsnitt beskrivs metoder för bra prestanda under ETL-processen, som dock inte har så stor betydelse för OLAP. 45

46 Den kanske viktigaste åtgärden för att få SQL med bra prestanda är inkrementell laddning. Med detta menas att varje steg i ETL-processen, för stora tabeller, bara laddar det data som faktiskt ändrats sedan förra laddningen, inte alltihop. Fullständig laddning tar dessutom längre och längre tid i takt med att den totala datavolymen ökar. Utnyttja partition pruning här! Det första steget laddar data som kommer från källsystemen, redan här bör datat vara inkrementellt. Några tips för hur man skriver SQL-kod med bra prestanda följer: Använd MERGE-kommandot istället för cursors där UPDATE eller INSERT görs för varje SELECT-varv i loopen. Använd direct load, dvs CTAS (Create Table As Select), eller INSERT/*+ APPEND */... AS SELECT, eller parallelism (som alltid ger direct load). NOLOGGING (hint eller attribut på tabellen), dvs laddning utan att skriva i redologgarna, kan snabba upp. Eftersom datat då inte kan återskapas vid en databaskrasch, tänk då på vilka tabeller som kan laddas om tillräckligt enkelt och vilka som inte kan det. Index som är definierade med NOLOGGING kan alltid återskapas. Den dåliga SQL-koden som beskrevs i förra avsnittet gäller förstås fortfarande. 46

47 Dålig SQL-kod, som beskrevs i Prestanda generellt, ska naturligtvis fortfarande undvikas. Vid inläsning av en fil: Använd en extern tabell (som pekar ut filen och har de kolumner som motsvarar filens format) istället för att läsa in filen till en temporär tabell med SQL*Loader, för att spara ett steg. Fördjupning Tänk dock på att en BAD-fil skapas (med poster som ej kan laddas in pga datafel) när den externa tabellen läses (inte när den skapas!), precis som SQL*Loader skapar en BAD-fil när den laddar felaktig data. Transportable tablespaces är det snabbaste sättet att flytta data mellan olika databaser (exempelvis från ett EDW till data marts). Det innebär att alla datafiler i tablespacet kopieras (med exempelvis ftp), ingen transformering sker alltså. 47

48 PEL står för Partition Exchange Load. Det innebär i normalfallet följande steg: 1. Töm (TRUNCATE) en temporär tabell. 2. Ladda den temporära tabellen med data. 3. Gör EXCHANGE PARTITION mellan den temporära tabellen och en partition i en partitionerad (fakta)tabell. Efteråt innhåller partitionen datat i den temporära, medan den temporära tabellen innehåller partitionens ursprungliga data (därför töms den temporära tabellen allra först, annars skulle där ju finnas data från den förra PEL-operationen). Bilden visar ett exempel på EXCHANGE PARTITION-kommandot. 48

49 EXCHANGE PARTITION tar noll tid, såvida inte man behöver validera att posterna i den temporära tabellen verkligen ryms inom partitionen (detta görs med WITH VALIDATION i EXCHANGE PARTITIONkommandot) eller det finns globala index i den partitionerade tabellen (de måste då uppdateras med UPDATE GLOBAL INDEXES för att inte bli UNUSABLE ) Den temporära tabellen måste vara identisk med den partitionerade, inklusive constraints. Lokala index i den partitionerade tabellen (som motsvaras av ett vanligt index i den temporära) följer med (om man vill, annars blir det UNUSABLE), det tar noll tid. Globala index i den partitionerade tabellen (exempelvis i form av PK /UK) måste alltså uppdateras, men den gamla versionen av indexet är kvar tills operationen är klar. Fördjupning Vad händer om man anger WITHOUT VALIDATION och det finns poster i den temporära tabellen som faller utanför partitionen? Jo, operationen går bra och datat kan läsas eller uppdateras utan problem. Om partition pruning fungerar kommer man dock att sakna dessa poster vid SELECTen, eftersom de ju ligger i fel partition! ANALYZE TABLE <tabell> VALIDATE STRUCTURE hittar de felaktiga posterna. Anger man WITH VALIDATION ges ett felmeddelande för felaktiga poster. 49

50 Varför gör man då PEL? Jo, faktatabellen är åtkomlig med den gamla datan under hela PEL-operationen, vilket gör att om en data mart laddas kan slutanvändarna jobba samtidigt. Man kan även tänka sig att diverse constraints finns i den temporära tabellen för att säkra bättre datakvalitet, dessa constraints tas sedan bort innan PEL-operationen görs. De finns alltså inte i den partitionerade tabellen där de kunde givit sämre prestanda (se Constraints strax). 50

51 Dubbel PEL används ibland, och innebär som man kanske kan gissa följande steg: 1. Töm (TRUNCATE) en temporär tabell. 2. Gör EXCHANGE PARTITION mellan den tempoära tabellen och en partition i en partitionerad (fakta)tabell. 3. Ladda den temporära tabellen med mer data, som alltså innehåller data redan från början. 4. Gör EXCHANGE PARTITION mellan den tempoära tabellen och samma partition en gång till. Varför gör man då detta? Ett exempel är om en MERGE ska göras till en partition, men partition pruning inte fungerar (dvs hela tabellen läses för att hitta posterna som ska uppdateras). Då kommer laddningen att ta lång tid (och längre tid efterhand som nya tidspartitioner läggs till). Skapa då en temporär tabell och gör dubbel PEL istället. Men: under PEL-operationen är partitionen tom! Slutanvändare kan alltså inte komma åt datat då. Alternativt, om man skippar det första steget, kommer partitionen att innehålla det gamla datat innan förra laddningen. 51

52 Primary Key (PK), Unique Key (UK), Foreign Key (FK): Detta är constraints som ju är till för att hålla ihop datamodellen, och säkra datakvaliteten. Ska dessa constraints vara ENABLED (dvs kontrolleras av Oracle under laddning, vilket tasr lite tid) eller DISABLED (kontrolleras ej under laddning)? Om ETL-koden är felfri (och gör alla nödvändiga kontroller på datat från källsystemen) fungerar DISABLED constraints... men hur ofta är kod felfri? Testa istället prestanda i respektive fall. Om ETLladdningen tar 2% längre tid med enablade constraints, anser jag att det är ett billigt pris att betala för en datamodell som faktiskt hänger ihop även i verkligheten. Förutom att felaktig data skapar problem för slutanvändarna, tar det även lång tid att korrigera felaktig data eftersom datavolymerna är så stora. 52

53 Det finns dock sätt att undvika att alla PK/UK/FK är enablade hela tiden, utan att tumma på dataintegriteten, när prestandan annars blir för dålig: DISABLE + ladda + ENABLE Man DISABLEar alltså constraints före laddningen (för PK/UK innebär det att motsvarande index tas bort), och ENABLEar dem efteråt (PK/UK-index skapas igen). Detta ger ofta en totalt sett snabbare laddning. ENABLE-operationen kommer dock att misslyckas om det finns fel i datat. PK/UK: DISABLE VALIDATE Här säger man alltså att constrainten gäller just nu (VALIDATE) men DISABLE gör att ingen data kan laddas på vanligt sätt (med DML, dvs INSERT/UPDATE/MERGE) eftersom Oracle då inte längre kan garantera att VALIDATE gäller. Något index för constrainten finns inte heller. Hur laddar man då en sådan tabell? Jo, tag bort constraint, ladda, skapa DISABLE VALIDATE constraint. Detta är mer effektivt än att skapa en ENABLED constraint eftersom inget index skapas, men skapandet kommer att misslyckas om det finns fel i datat. PK/UK DISABLED för surrogatnyckel Eftersom en surrogatnyckel är implementerad som en sekvens, kan man lita på att sekvensen inte genererar dubletter långt mer än man kan lita på ETL-koden. Om indexet för surrogatnyckeln inte behöver användas av queries, kan man därmed låta PK/UKn vara DISABLED. Fördjupning En annan variant för DISABLE VALIDATE är att använd apel (DDL), dvs constrainten var ENABLED när den temporära tabellen laddades och ändrades sedan till DISABLED. 53

54 Sekvenser används som redan nämnts (se Nycklar i databasen i avsnittet Om datalager ) för att skapa surrogatnycklar. Första gången sekvensen läses fås (per default) värdet 1, nästa gång 2 osv. Per default, kommer Oracle var 20:e gång sekvensen läses (samt första gången i varje session) att cacha sekvens-värdena. Om värdet på sekvensen är 56 när den läses, lägger Oracle alltså in värdena 56 t.o.m. 75 i cachen, så de 19 följande läsningarna kommer att läsa från cachen och inte från sekvensens egen tabell (som är en intern tabell i Oracle). Om sekvens-läsningarna avbryts innan 19 stycken gjorts, kommer de sista sekvens-nummerna aldrig att utnyttjas. Nästa gång sekvensen används kommer följaktligen 76 t.o.m. 85 att returneras i cachen. I snitt fås alltså ett hål på 10 i surrogatnyckel-sekvensen efter varje laddning. Nu visar det sig att om en tabell snabbt fylls med data (exempelvis 10 miljoner poster), inklusive en kolumn som laddas från en sekvens, har cache-storleken betydelse. Default-värdet på 20 är så litet att prestandan märkbart försämras under laddningen av tabellen pga tiden Oracle får lägga ner på sekvens-läsandet varje gång cachen är tom. Lösningen är helt enkelt att öka CACHE-värdet på sekvensen till exempelvis Den enda nackdelen är att hålet i surrogatnyckel-sekvensen kommer att bli större (i genomsnitt 500 istället för 10). 54

55 OLAP är i detta sammanhang beteckningen på all data-access som slutanvändarna gör i data marts och/eller OLAP-kuber. Användarna ser normalt datat i en stjärnmodell, och de väljer olika villkor i de olika dimensionerna som de sedan vill se faktadatat för. De flesta användare behöver oftast inte datat på den lägsta nivån (exempelvis försäljning per försäljningsställe per dag per kund), utan nöjer sig med data i en aggregrerad form (exempelvis försäljning per land per vecka för alla privatkunder). Användarna kan sedan borra ner sig, dvs gå ner i dimensionshierarkin, och en minoritet av användarna kan vara intresserade av ofiltrerad data på den lägsta nivån. I detta avsnitt beskrivs metoder för bra prestanda för OLAP (slutanvändarqueries), som dock inte har så stor betydelse för ETL-processen. 55

56 Bara SELECT finns i OLAP-SQL-koden. Dålig SQL-kod, som beskrevs i Prestanda generellt, ska naturligtvis fortfarande undvikas. Mycket TEMP-utrymme behövs, eftersom tunga sorteringar ofta behöver göras och det kan finnas många användare. Om en en ensam query behöver väldigt mycket TEMP är det dock förmodligen något fel på queryn. 56

57 En materialiserad vy innebär att aggregering (dvs exempelvis SUM med GROUP BY) och/eller join av bastabeller görs till en fysisk (materialiserad) vy, en speciell tabell som Oracle sköter laddningen av. Oracle kan även styra om SQL-frågor mot bastabellerna så att de går mot den materialiserade vyn istället, så kallad query rewrite. Varför ska man då använda sig av materialiserade vyer (matvyer)? Jo, aggregerad data blir mycket mindre än datat på detaljnivå (förutsatt att man aggregerar tillräckligt mycket). Eftersom aggregerade nivåer ofta räcker i en slutanvändarquery blir den därmed mycket snabbare (sedan kan användaren vid behov gräva ner sig i bastabellerna för att få detaljer). En materialiserad vy som består av joinade tabeller snabbar även den upp om joinen är tung. Möjligheten att styra om SQL innebär att OLAP-verktyget enbart känner till bastabellerna. Oracle omvandlar sedan SQL innehållande SUM med GROUP BY så att den jobbar mot lämpliga materialiserade vyer istället. På så vis kan de materialiserade vyerna tas bort, ändras, eller nya läggas till, utan att modellen i OLAPverktyget behöver ändras. Materialiserade vyer finns ju enbart av prestanda-skäl, så det värsta som kan hända är att en OLAP-query går långsammare. Query rewrite kräver dock att OLAP-verktyget genererar SQL som är kompatibel med matvyn (exakt samma SUM med exakt samma GROUP BY-uttryck till exempel), så det krävs övervakning för att se till att det fungerar. Fördjupning En liknande teknik används i en OLAP-kub, som dock aggregerar på alla nivåer samtidigt (motsvarande alla tänkbara matvyer). 57

58 Någon kanske invänder att man själv kan bygga och ladda sina egna tabeller med aggregerad/joinad data. Fördelarna med matvyer är: Man slipper själv hålla reda på vad som ändrats i bastabellerna => Oracle kan göra inkrementell (FAST REFRESH) uppdatering av de materialiserade vyerna, dvs endast ändrad data uppdaterar dem. Det går betydligt snabbare att uppdatera en matvy inkrementellt än fullt (COMPLETE REFRESH), en full uppdatering kommer desssutom att ta längre och längre tid allt eftersom bastabellerna växer. Man kan själv bestämma när matvyarna ska uppdateras, direkt vid COMMIT av bastabellerna eller vid ett senare tillfälle (i datalager väntar man oftast till slutet av ETL-processen). Man får Query rewrite, och slipper därmed modellera även de egna aggregeringarna i OLAP-verktyget (och ändra modellen när man hittar på nya). Matvyerna kan bygga på varandra, dvs en matvy kan definieras som innehållet i en eller flera andra matvyer, och fortfarande laddas inkrementellt (med vissa restriktioner). 58

59 Matvyer fungerade ganska dåligt när de kom i Oracle 8i, och har därmed fått ett lite dåligt rykte. De har dock blivit betydligt bättre sedan dess: FAST REFRESH fungerar verkligen, i 8i fanns gott om begränsningar när det inte fungerade. I 8i höll Oracle alltid reda på vilka poster i bastabellerna som uppdaterats sedan förra FAST REFRESHen genom att lägga uppdateringarna i materialiserade vyloggar, speciella logg-tabeller alltså. Dess loggtabeller tar givetvis plats, samt tid att uppdatera vid bastabell-uppdateringen och tid att läsa vid FAST REFRESHen. I 10g kan dessa loggtabeller fortfarande användas, men om laddningen av bastabeller sker med direct load så utnyttjas inte matvy-loggarna, de förblir tomma (men måste ändå finnas). Istället lagrar Oracle ROWID-intervall i speciella interna tabeller (direct load innebär ju att hela sjok av block laddas), som blir mycket små och därmed snabba. Partition Change Tracking, PCT: Detta innebär att Oracle håller reda på i vilka partitioner av bastabeller som uppdateringar skett när FAST REFRESH ska göras av matvyerna. Fördjupning Vid PEL av bastabellerna är PCT det enda sättet att få FAST REFRESH, eftersom bastabellerna ju inte laddats med DML utan med DDL (EXCHANGE PARTITION), det finns alltså inga matvy-loggar eller interna tabeller att titta i. Det innebär alltså att hela partitionen i bastabellen laddar om motsvarande poster i matvyn. Även när bastabellerna inte är PEL-laddade kan PCT snabba upp FAST REFRESHen. 59

60 PCT kan lämpligen kombineras med partitionering av matvyn. Eftersom matvyer ofta är aggregerade, kan exempelvis en dag-partitionerad bastabell ladda en veckopartitionerad matvy. Sju dag-partitioner i bastabellen motsvarar då en vecko-partition i matvyn. Vid FAST REFRESH kan då Oracle göra TRUNCATE på vecko-partitionen och sedan ladda den (INSERT) från samtliga dag-partitioner, även om bara en av dem ändrats. Alternativet vore att göra DELETE+INSERT (UPDATE görs aldrig i matvyer) av alla vecko-poster som påverkas av den ändrade dag-partitionen, men detta kan vara långsammare än TRUNCATE + omladdning eftersom posterna att uppdatera (vilket kan vara de flesta i vecko-partitionen) måste letas upp först. Varning: Skapa inte alltid materialiserade vyer! Aggregerade matvyer bör vara åtminstone några gånger mindre än bastabellen, annars kan vinsten att läsa mindre data bli uppäten av tiden det tar att refresha matvyn. För matvyer som består av joins (eventuellt kombinerat med aggregering) är det svårare att veta var brytpunkten finns. Det är lätt hänt att fler och fler matvyer läggs till för att snabba upp än den ena, än den andra OLAP-queryn. Detta ger längre och längre refresh-tider (samt större och större diskåtgång). Alla querys kan inte optimeras på detta sätt, utan man får nöja sig med de viktigaste. Se upp med matvyer som en gång skapats för en OLAP-queries som inte längre finns alls (tag då bort dem), eller som inte längre fungerar eftersom SQL-koden inte längre matchar som den ska (gör då om dem). Fördjupning 11g: Materialiserade vyer kan implementeras som OLAP-kuber i databasen, så att alla tänkbara matvyer för olika aggregeringar av en faktatabell blir en enda OLAP-kub (som i 11g kan accessas även med SQL och inte bara med ett speciellt OLAPgränssnitt). 60

61 Tyvärr är inte all optimering av godo (även om det finns pengar till jobbet, och till mer disk för att exempelvis få plats med index och materialiserade vyer). Ibland kan nämligen optimering som ger snabbare ETL ge långsammare OLAP, och vice versa. Det kan även hända att man får motstridig prestanda mellan de olika ETL-stegen. Om detta ska detta avnitt handla. 61

62 Redan innan vi börjat optimera, finns motstridiga krav: Användarna kräver snabba queries och aktuell data! Aktuellare data => snabbare ETL krävs. Om ETL-processen optimeras på dataåtkomstens bekostnad (exempelvis färre index och materialiserade vyer), blir användarna missnöjda med svarstiderna... ETL/underhålls-fönster med OLAP 24/7? Har man nätterna på sig för sin ETL, och allt nödvändigt underhåll, är allt förhoppningsvis gott och väl. Men i multinationella företag med användare i alla tidszoner har man inga laddfönster alls! Laddningen måste alltså ske under drift. Hur detta görs är dock en annan kurs (sök på Real-time data warehousing och liknande). Många steg i ETL-processen Många steg (Staging area => EDW => data marts => OLAP-kuber) ger långa ETLtider. Kuber ger snabb åtkomst, nedborrning kräver optimerade data marts. De många stegen krävs vid en EDW-lösning, som enligt förespråkarna ger snabbare utveckling och bättre kvalitet (vilket också användarna kräver). Använder man sig av data marts direkt efter staging arean blir laddningen snabbare, men samma kod (och temporära tabeller) kan då behövas på flera ställen. Eftersom även kuberna tar tid att ladda, kan man låta användarna jobba direkt mot data martsen istället detta ger dock sämre prestanda än kubaccess (så länge datamängderna inte är alltför stora). 62

63 Vilka optimeringar för snabbare ETL ger då långsammare OLAP, eller tvärtom? Denormaliserade tabeller Detta ger snabbare OLAP, men långsammare och mer komplex ETL. Om en kolumn dupliceras i två andra tabeller, tar givetvis uppdateringen längre tid. Å andra sidan kan slutanvändarquerien, eller nästa steg i ETL-processen, slippa två joins... Vilket är då bäst? Det inte speciellt tillfredsställande svaret blir: Denormalisera lagom mycket! Partitionering hur och på vilka nycklar? En data mart-tabell kanske används av OLAP-queries med ett villkor på en typkolumn som gör att list-partitionering ger bäst resultat med hjälp av partition pruning. Om laddningen av tabellen sker för alla typer i listan för ett visst datum, kan rangepartitionering på tid ge den snabbaste laddningen (partition pruning igen). Lösning: Range list, vilket gör att OLAP-queryn visserligen får leta igenom alla datumpartitioner, men fortfarande bara för de sub-partitioner som motsvarar typkolumnen (OLAP-queryn blir ännu effektivare om även datumet finns med i queryn). Samma problem kan även uppstå i de olika ETL-stegen, där en tabell som är rangepartitionerad på ett datum för att laddningen av den ska gå snabbt, borde behöva vara range-partitionerad på ett annat datum för att nästa laddsteg ska kunna läsa endast det nya/ändrade datat från tabellen (typ UPDATE_DATE). Lösning: Testa vilket alternativ som vinner. 11g: Range range. 63

64 Index och materialiserade vyer Detta ger snabbare OLAP, men ger långsammare ETL. För små indexerade tabeller behöver man inte bekymra sig om långsam laddning eftersom den går väldigt snabbt i alla fall (för riktigt små tabeller gör index förmodligen ingen nytta alls). För partitionerade (stora) tabeller bör indexen vara lokala så långt som möjligt, för att snabba upp laddningen. Om detta inte går eller hjälper, finns inte mycket annat att göra än att kompromissa! Vad gäller materialiserade vyer, bör de som tidigare nämnts inte vara för många. Alla OLAP-queries kan inte gå blixtsnabbt, men de riktigt viktiga bör göra det. Komprimering En SELECT (som används i OLAP eller ETL) mot en komprimerad tabell går normalt snabbare än mot en okomprimerad, medan DML=INSERT/UPDATE/MERGE (som används i ETL) går långsammare. Eftersom även ETL som gör SELECT mot en annan komprimerad tabell går snabbare, kan komprimering löna sig i många fall. Gamla partitioner kan komprimeras i efterhand, eftersom de då normalt inte längre uppdateras. 11g: Här ska en effektivare komprimering göra att såväl SELECT som DML går snabbare eller lika snabbt. 64

65 Som en sammanfattning till hela presentationen följer här ett recept på bra prestanda i datalager. Observera att rangordningen i receptet inte är det viktiga i sammanhanget. 65

66 Om vi börjar med huvudrätten, dvs databasen, ser receptet ut så här: 1. Statistik: Eftersom datavolymerna är stora i datalager, är det extra viktigt att statistiken samlas in regelbundet. Per default görs detta automatiskt. 2. Partitionering: Man kan inte förlora mycket på att partitionera en stor tabell, jämfört med att inte partitionera den alls. En genomtänkt partitionering kan med hjälp av partition pruning däremot ge stora prestandavinster. 3. Parallelism: Utnyttja alla dina CPU-er och SAN-diskar för skalbarhet! Annars kostar de bara onödiga pengar Denormalisering: Snabba upp OLAP och ETL-SELECT, utan att komplicera ETL- DML alltför mycket. 5. Komprimering: Gör detta på de historiska faktatabellerna, åtminstone på gamla partitioner. 6. Materialiserade vyer: Skapa dessa för att ge snabb OLAP där det verkligen är nödvändigt. 7. Index: Skapa index (såväl normala som bitmap) för lookuper och OLAP-queries. 8. Kör advisors: Förenkla SGA/PGA-hanteringen, låt SQL Tuning Advisor skapa SQL-profiler när det behövs, låt SQL Access Advisor rekommendera index och matvyer, låt ADDM ge råd om långsamma queries, och låt Segment Advisor hitta fragmenterade tabeller. 66