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

Storlek: px
Starta visningen från sidan:

Download "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

Datalager och datautvinning

Datalager och datautvinning Datalager och datautvinning 1 Datalager och datautvinning! Databaser kan innehålla stora mängder information om ett företags eller en organisations verksamhet" Data kan också användas för att analysera

Läs mer

Lär känna MS SQL 2008 / Övning. Observera. Tips. Förberedelse

Lär känna MS SQL 2008 / Övning. Observera. Tips. Förberedelse Lär känna MS SQL 2008 / Övning Observera Övningar som finns tillgängliga är till för att du ska kunna testa dina kunskaper och träna på dem. Det är helt upp till dig när du vill genomföra och om du vill

Läs mer

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista

Vad är en databas? Databaser. Relationsdatabas. Vad är en databashanterare? Vad du ska lära dig: Ordlista Databaser Vad är en databas? Vad du ska lära dig: Använda UML för att modellera ett system Förstå hur modellen kan översättas till en relationsdatabas Använda SQL för att ställa frågor till databasen Använda

Läs mer

Structured query language (SQL)

Structured query language (SQL) Structured query language SQL) Varför SQL? SQL är ett standardspråk som är oberoende av databashanteringssystemen som finns på marknaden. Med andra ord kommer du kunna arbeta mot nästan alla sorters relationsdatabaser

Läs mer

Databashantering och Beslutsstöd

Databashantering och Beslutsstöd Högskolan i Halmstad Sektionen för ekonomi och teknik Affärssystemprogrammet Databashantering och beslutsstöd, 7,5 hp Examinator Jesper Hakeröd 2011-02-25 Databashantering och Beslutsstöd Namn Innehållsförteckning

Läs mer

Labb LIVE. Exempelkod från föreläsningen. Plushögskolan Frågeutveckling inom MSSQL - SU14

Labb LIVE. Exempelkod från föreläsningen. Plushögskolan Frågeutveckling inom MSSQL - SU14 Labb LIVE Exempelkod från föreläsningen Plushögskolan Frågeutveckling inom MSSQL - SU14 Här kommer exempelkoden jag använde under föreläsningen Exemplen Constraints... 2 Transactions... 4 Views... 5 Functions...

Läs mer

Fö 8: Operativsystem II. Minneshantering. Minneshantering (1) Minneshantering (2) Minneshantering och Virtuelltminne.

Fö 8: Operativsystem II. Minneshantering. Minneshantering (1) Minneshantering (2) Minneshantering och Virtuelltminne. Fö 8: Operativsystem II Minneshantering och Virtuelltminne. Virtuella I/O enheter och Filsystemet. Flerprocessorsystem. Minneshantering Uniprogrammering: Minnet delas mellan operativsystem och användarprogrammet.

Läs mer

Tentamen i Databasteknik

Tentamen i Databasteknik Tentamen i Onsdagen den 7 mars 2007 Tillåtna hjälpmedel: Allt skrivet material Använd bara framsidan på varje blad. Skriv max en uppgift per blad. Motivera allt, dokumentera egna antaganden. Oläslig/obegriplig

Läs mer

Övningar i SQL. SQLAccess.doc Ove Lundgren 2000-11-14

Övningar i SQL. SQLAccess.doc Ove Lundgren 2000-11-14 Övningar i SQL Övningar i SQL Använd Access för att öva SQL (= Structured Query Language) Skapa tabeller med SQL 1. Ny databas: SQLÖVNING Klicka: Frågor > Ny > Design > OK >Stäng > SQL Radera ordet SELECT.

Läs mer

INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA...

INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA... INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA...6 2 (6) 2D1954 Programutvecklingsprojekt vt 2003 Installation

Läs mer

Dagens föreläsning. KTH & SU, CSC Databasteknik Föreläsning 10 sid 1

Dagens föreläsning. KTH & SU, CSC Databasteknik Föreläsning 10 sid 1 Dagens föreläsning Vad du skall komma ihåg från tidigare föreläsningar Optimering av frågor Algebraisk omformulering Kostnadsberäkningar Evaluering av frågor Algoritmer för relationsoperatorer Beräkning

Läs mer

DI Studio 4.3 - nyheter

DI Studio 4.3 - nyheter DI Studio 4.3 - nyheter Sofie Eidensten och Patric Hamilton Copyright 2010 SAS Institute Inc. All rights reserved. 2 Varför DI Studio Snabbare utveckling Enklare underhåll Gör det överskådligt 3 Nyheter

Läs mer

Vad du skall komma ihåg från tidigare föreläsningar. Dagens föreläsning. Evaluering av frågor. Data dictionary

Vad du skall komma ihåg från tidigare föreläsningar. Dagens föreläsning. Evaluering av frågor. Data dictionary Dagens föreläsning Vad du skall komma ihåg från tidigare föreläsningar Vad du skall komma ihåg från tidigare föreläsningar Optimering av frågor Algebraisk omformulering Kostnadsberäkningar Evaluering av

Läs mer

Tentamen i Databasteknik

Tentamen i Databasteknik Tentamen i Lördagen den 21 oktober 2006 Tillåtna hjälpmedel: Allt skrivet material Använd bara framsidan på varje blad. Skriv max en uppgift per blad. Motivera allt, dokumentera egna antaganden. Oläslig/obegriplig

Läs mer

Labb LABB 1. Databassagan och en rundtur i databasers märkliga värld. Plushögskolan Frågeutveckling inom MSSQL - SU14

Labb LABB 1. Databassagan och en rundtur i databasers märkliga värld. Plushögskolan Frågeutveckling inom MSSQL - SU14 Labb LABB 1 Databassagan och en rundtur i databasers märkliga värld Plushögskolan Frågeutveckling inom MSSQL - SU14 I Microsoft SQL-Server Management Studio kan man arbeta på olika sätt. Antingen via användargränssnittet

Läs mer

Stored procedure i ASP.NET

Stored procedure i ASP.NET Stored procedure i ASP.NET OBS! Om du vill jobba med att skapa en stored procedure i en SQL Serverdatabas ifrån VS2010 måste du ha fullversion, expressversionen tillåter dig ej att skapa triggers, stored

Läs mer

! Teori och praktik. ! Ändringar från förra året. ! Examination (tenta, projekt) LiU. ! Varför ni? ! Varför överhuvudtaget? LiU

! Teori och praktik. ! Ändringar från förra året. ! Examination (tenta, projekt) LiU. ! Varför ni? ! Varför överhuvudtaget? LiU Databaser Design och programmering, IDA Kursen, diverse praktiskt Varför databaser? Vad är en databas? Andra viktiga begrepp Kursöversikt Teori och praktik Fö och bok lektioner, labbar i projekt (3,5hp=100h)

Läs mer

Kunskapsbank ICARUS DB

Kunskapsbank ICARUS DB Kunskapsbank ICARUS DB K E Y L O G I C A B 1 Innehållsförteckning 1 Innehållsförteckning 1 2 SQL Server 2005 3 2.1 Installation 3 2.2 Användargränssnitt (DBMS) för SQL Express 3 2.3 Undvik att transaktionsloggen

Läs mer

TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007

TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007 Linköpings tekniska högskola ITN / Campus Norrköping Jan Petersson Uppdaterad av Marky Egebäck 17 november 2009 TNK046 GIS - Databaser Laborationsuppgift 1 Introduktion till Microsoft Access 2007 Översikt

Läs mer

Föreläsning 6 Databaser och säkerhet

Föreläsning 6 Databaser och säkerhet Databasbaserad publicering Föreläsning 6 1 Föreläsning 6 Databaser och säkerhet & Läs kapitel 13 i Databasteknik och kapitel 9 i boken PHP & MySQL: Novice to Ninja Databasbaserad publicering Föreläsning

Läs mer

Modul DB1-1 Databasmodellering

Modul DB1-1 Databasmodellering Modul DB1-1 Databasmodellering Antal föreläsningar: 2 Antal laborationer: 1 Förkunskapskrav: Databasintroduktion Kurslitteratur: Referenslitteratur: Praktisk datamodellering ISBN: 91-44-38001-1 1 Innehållsförteckning

Läs mer

VAD GÖR DU / VEM ÄR DU?

VAD GÖR DU / VEM ÄR DU? INNEHÅLL Vad blir din roll Databaser vad är och varför Terminologi Datamodellering vad är och varför Utvecklingsprocessen SQL vad är det Data / Information / Kunskap Kapitel 1 delar av. Praktisk Datamodellering

Läs mer

L0009B. Moment. Introduktion till geografiska databaser: G:\L0009B\Allmänt\IntroGeoDB.pdf (F)

L0009B. Moment. Introduktion till geografiska databaser: G:\L0009B\Allmänt\IntroGeoDB.pdf (F) L0009B Moment FL 1: Kursintroduktion. Kursinformation: G:\L0009B\Allmänt\KursInformationL0009B.pdf (F) Kursplan: Se https://portal.student.ltu.se/stuka/kurs.php?kurs=l0009b&lang=swe (F) Allt som markerats

Läs mer

Karlstads Universitet, Datavetenskap 1

Karlstads Universitet, Datavetenskap 1 2003-01-20 DAV B04 - Databasteknik 2003-01-20 KaU - Datavetenskap - DAV B04 - MGö 26 Relationsmodellen En formell teori som baserar sig på (främst) mängdlära predikatlogik Föreslogs av E.F Codd 1970 i

Läs mer

Ny skalbar och öppen OLAP-teknologi, SAS OLAP server

Ny skalbar och öppen OLAP-teknologi, SAS OLAP server Ny skalbar och öppen OLAP-teknologi, SAS OLAP server Frida Säfström Seniorkonsult Copyright 2003, SAS Institute Inc. All rights reserved. Agenda Arkitekturen Lagring Skalbarhet Säkerhet Olika typer av

Läs mer

Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva

Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva OBS! Det finns ytterligare filer på Microsoft CD, som tillhör SQL 2000 Administration Self paced, vilka kan

Läs mer

Laborationer - databaser, EDAA20 Programmering och databaser

Laborationer - databaser, EDAA20 Programmering och databaser LUNDS TEKNISKA HÖGSKOLA EDAA20 Programmering och databaser Institutionen för datavetenskap HT 2015 Laborationer - databaser, EDAA20 Programmering och databaser I kursens databasdel ingår två obligatoriska

Läs mer

IRONCAD KONFIGURATIONER

IRONCAD KONFIGURATIONER IRONCAD KONFIGURATIONER IRONCAD har något som kallas för konfigurationer eller configurations på engelska. Det innebär att sammanställningar, parter och features i en och samma 3D-fil kan ha olika positioner

Läs mer

KAP 18 SQL SERVER AGENT

KAP 18 SQL SERVER AGENT KAP 18 SQL SERVER AGENT Tjänsten Sql Server Agent Operator Job Alert (larm) http://www.youtube.com/watch?v=ii1tc493bzm 1 VAD ÄR SQL SERVER AGENT? SQL Server Agent är en tjänst (service) som ansvarar för:

Läs mer

Administrationsmanual ImageBank 2

Administrationsmanual ImageBank 2 Document information ID: P001 Appendix C Rev: 4 Author: Tomas von Peltzer Product nr: Title: Reviewed by: Approved by: P001 ImageBank Administration Manual Product name: Ingvar Falconer Date: 2014-10-22

Läs mer

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen för DD1370 Databasteknik och informationssystem Tentamen för DD1370 Databasteknik och informationssystem 24 Augusti 2015 Hjälpmedel: Inga hjälpmedel utom papper och penna Tänk på: Skriv högst en uppgift på varje blad. Använd endast framsidan på varje

Läs mer

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1 Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1 Allmänt Releasen omfattar uppgradering av Tekis Aviseringsprogram version 6.3.1 (för både Tekis-FIR och Tekis-KID avisering) samt databasuppgradering

Läs mer

En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson

En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson Acando Johan Petersson Visit me at LinkedIn: se.linkedin.com/in/johpet 2 Acando 2014-29-08 Acando - översikt Enterprise Consulting

Läs mer

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1 Inlämningsuppgift : Finn 2D1418 Språkteknologi Christoffer Sabel E-post: csabel@kth.se 1 1. Inledning...3 2. Teori...3 2.1 Termdokumentmatrisen...3 2.2 Finn...4 3. Implementation...4 3.1 Databasen...4

Läs mer

Användarmanual LOCKBEE - Business. En produktion av Avtre AB

Användarmanual LOCKBEE - Business. En produktion av Avtre AB Användarmanual LOCKBEE - Business En produktion av Avtre AB Användarmanual för Lockbee - Business Användarmanualen är avsedd att ge en närmare introduktion av Lockbees funktioner och nyttjande. Vi rekommenderar

Läs mer

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen för DD1370 Databasteknik och informationssystem Tentamen för DD1370 Databasteknik och informationssystem 16 Januari 2015 Hjälpmedel: Inga hjälpmedel utom papper och penna Tänk på: Skriv högst en uppgift på varje blad. Använd endast framsidan på varje

Läs mer

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: 033-4354424. Anslås inom 3 veckor

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: 033-4354424. Anslås inom 3 veckor TENTAMEN För kursen DATUM: 2013-12-12 TID: 9 14 Ansvarig för tentamen: Cecilia Sönströd Förfrågningar: 033-4354424 Resultat: Betygsskala: Hjälpmedel: Anslås inom 3 veckor Godkänt 20 p, Väl godkänt 32 p,

Läs mer

SCB Räkenskapssammandrag

SCB Räkenskapssammandrag SCB Räkenskapssammandrag SCB Räkenskapssammandrag 1 1. KOMMA IGÅNG MED PROGRAMMET... 2 1.1 ÖVERSIKT FÖRBEREDELSER... 2 1.2 STARTA PROGRAMMET... 3 1.3 ÖVERSIKT SCB MENY... 5 1.4 INSTÄLLNINGAR... 6 1.5 KOLUMNER...

Läs mer

NYHETER I AUTOCAD 2006

NYHETER I AUTOCAD 2006 NYHETER I AUTOCAD 2006 Nedan följer en kort beskrivning av nyheter och förbättringar i AutoCAD 2006, jämfört med AutoCAD 2005. Nyheterna är inte ordnade i speciell ordning. KOMMANDOT JOIN Med det nya kommandot

Läs mer

www.drakbutiken.se IDE USB kabel Windows XP, Vista 7 löäzxcvbnmqwertyuiopåasdfghjklöäz [Version 1.4, 2009-11-01] www.drakbutiken.

www.drakbutiken.se IDE USB kabel Windows XP, Vista 7 löäzxcvbnmqwertyuiopåasdfghjklöäz [Version 1.4, 2009-11-01] www.drakbutiken. qwertyuiopåasdfghjklöäzxcvbnmqwe rtyuiopåasdfghjklöäzxcvbnmqwertyu iopåasdfghjklöäzxcvbnmqwertyuiopå asdfghjklöäzxcvbnmqwertyuiopåasdf ghjklöäzxcvbnmqwertyuiopåasdfghjk www.drakbutiken.se IDE USB kabel

Läs mer

TENTAMEN I PROGRAMMERING. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng

TENTAMEN I PROGRAMMERING. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng TENTAMEN I PROGRAMMERING Ansvarig: Jan Skansholm, tel 7721012 Betygsgränser: Hjälpmedel: Sammanlagt maximalt 60 poäng. På tentamen ges graderade betyg:. 3:a 24 poäng, 4:a 36 poäng och 5:a 48 poäng Skansholm,

Läs mer

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: 033-4354424. Anslås inom 3 veckor

TENTAMEN. För kursen. Databasteknik. Ansvarig för tentamen: Cecilia Sönströd. Förfrågningar: 033-4354424. Anslås inom 3 veckor TENTAMEN För kursen DATUM: 2014-08-20 TID: 9 14 Ansvarig för tentamen: Cecilia Sönströd Förfrågningar: 033-4354424 Resultat: Betygsskala: Hjälpmedel: Anslås inom 3 veckor Godkänt 20 p, Väl godkänt 32 p,

Läs mer

Webbprogrammering, grundkurs 725G54

Webbprogrammering, grundkurs 725G54 Webbprogrammering, grundkurs 725G54 Bootstrap jquery SEO RWD MuddyCards. Tidigare Muddycards Många positiva kommentarer Ibland för högt tempo på föreläsning Lägg ut labbar tidigare Mer föreläsningar (2

Läs mer

Frågeoptimering. Frågeoptimering kapitel 14

Frågeoptimering. Frågeoptimering kapitel 14 Frågeoptimering kapitel 14 Frågeoptimering sid Introduktion 1 Transformering av relationsuttyck 4 Kataloginformation för kostnadsestimering Statisk information för kostnadsestimering Kostnadsbaserad optimering

Läs mer

Säkerhetsinställningar, websolen. Innehåll

Säkerhetsinställningar, websolen. Innehåll Innehåll 1 Säkerhetsinställningar i websolen... 2 1.1 Varför behövs detta?... 2 1.2 Instruktion, Internet Explorer 11... 2 1.2.1 Lägg till websolen som betrodd plats... 2 1.2.2 Både http och https... 4

Läs mer

komplett kopia av hårddisken 20 minu En instabil dator som ofta drabbas av fel får du snabbt på rätt kurs med en kopia av Windows och alla program.

komplett kopia av hårddisken 20 minu En instabil dator som ofta drabbas av fel får du snabbt på rätt kurs med en kopia av Windows och alla program. fakta En instabil dator som ofta drabbas av fel får du snabbt på rätt kurs med en kopia av Windows och alla program. det här behöver du En extern hårddisk, dvd eller tillgång till en NAS. kostnad Ingen,

Läs mer

Administrationsmanual ImageBank 2

Administrationsmanual ImageBank 2 Administrationsmanual ImageBank 2 INNEHÅLL 1. Konventioner i manualen 3 2. Uppmärksamhetssymboler 3 3. Vad är imagebank SysAdmin 4 4. Guide för att snabbt komma igång 5 5. Uppgradera din imagebank 1.2

Läs mer

Volvo Information Technology. Volvo Information Technology HåkanEnarson, 2004-01-13

Volvo Information Technology. Volvo Information Technology HåkanEnarson, 2004-01-13 1 !"#$%!&'(%!) %%%*!+ % %%%% 2 RUG 2003, alternativ till DB2 Connect? Nu nytt avtal på en rimligare nivå som ger oss flexibilitet Konsolidering av Mainframe till Göteborg Gateway maskiner med DB2 Connect

Läs mer

Workshop IBA internet based assessment

Workshop IBA internet based assessment Workshop IBA internet based assessment 2003-04-02 Ulf Jonsson Målsätttning Efter denna workshop så skall du förstå/kunna: * Beskriva olika delarna som ingår i verktyget Perception. * Konstruera enkla frågor

Läs mer

KAP 16 BACKUP, RESTORE OCH RECOVERY

KAP 16 BACKUP, RESTORE OCH RECOVERY KAP 16 BACKUP, RESTORE OCH RECOVERY Backup - strategier Backuptyper Recoverymodeller Backup med Management Studio Backup med TSQL Hur transaktionsloggen fungerar Automatiskt återhämtning (Recovery) Återhämta

Läs mer

Malmqvist, Daniel. Daniel Verhoeff [dav@mark-info.com] Skickat: den 2 juni 2009 16:22 Till: Från: Malmqvist, Daniel Ämne: RE: Brana Supporten

Malmqvist, Daniel. Daniel Verhoeff [dav@mark-info.com] Skickat: den 2 juni 2009 16:22 Till: Från: Malmqvist, Daniel Ämne: RE: Brana Supporten Malmqvist, Daniel Från: Daniel Verhoeff [dav@mark-info.com] Skickat: den 2 juni 2009 16:22 Till: Malmqvist, Daniel Ämne: RE: Brana Supporten Vilket terminal nummer har du upprättat i BranaTime sa du? From:

Läs mer

Tentamen. i Databasteknik. lördagen den 13 mars 2004. Tillåtna hjälpmedel: Allt upptänkligt material

Tentamen. i Databasteknik. lördagen den 13 mars 2004. Tillåtna hjälpmedel: Allt upptänkligt material Tentamen i lördagen den 13 mars 2004 Tillåtna hjälpmedel: Allt upptänkligt material Använd bara framsidan på varje blad. Skriv max en uppgift per blad. Motivera allt, dokumentera egna antaganden. Oläslig/obegriplig

Läs mer

Kontoersättning i Pyramid - Arbetsgång

Kontoersättning i Pyramid - Arbetsgång Kontoersättning i Pyramid - Arbetsgång (Pyramid Business Studio från version 3.41A) (2013-11-27) I detta dokument beskrivs arbetsgången i Pyramid rutin 962 Kontoersättning. Dialogen ger möjlighet att utföra

Läs mer

Dokumentation för VLDIT AB. Online classroom

Dokumentation för VLDIT AB. Online classroom Dokumentation för VLDIT AB Online classroom 2 Introduktion VLDIT AB önskar area för att tillhandahålla ett kursutbud online för sina befintliga deltagare, men även för nya. Syfte för applikationen: tillhandhålla

Läs mer

Databaser - Design och programmering. Minnesteknik. Minnesteknik, forts. Hårddisk. Primärminne (kretsteknik) Fysisk design av databasen

Databaser - Design och programmering. Minnesteknik. Minnesteknik, forts. Hårddisk. Primärminne (kretsteknik) Fysisk design av databasen Databaser Design och programmering Fysisk design av databasen att ta hänsyn till implementationsaspekter minnesteknik filstrukturer indexering Minnesteknik Primärminne (kretsteknik) Flyktigt Snabbt Dyrt

Läs mer

Tentamen för DD1370 Databasteknik och informationssystem

Tentamen för DD1370 Databasteknik och informationssystem Tentamen för DD1370 Databasteknik och informationssystem 13 Mars 2014 Hjälpmedel: Inga hjälpmedel utom papper och penna Tänk på: Skriv högst en uppgift på varje blad. Använd endast framsidan på varje blad.

Läs mer

ETL-verktyg för datavaruhus

ETL-verktyg för datavaruhus Examensarbete vid institutionen för datavetenskap Umeå Universitet Författare: Johan Unger Handledare: Tommy Jakobsen (ABB Power Technology Products AB) Johan Karlsson (Umeå Universitet)

Läs mer

Allt du behöver för crowdsourcing

Allt du behöver för crowdsourcing GUIDE Allt du behöver för crowdsourcing DEL 2: Så här följer och visar du resultatet i en dashboard Allt du behöver för crowdsourcing den kompletta guiden steg för steg, del 2 För att utföra uppgifterna

Läs mer

Uppgift 1a (Aktiekurser utan poster)

Uppgift 1a (Aktiekurser utan poster) Uppgift 1a (Aktiekurser utan poster) Vi har lite olika upplägg i de kurser vi håller och i vissa kurser finns det med något som vi kallar "poster" (eng. "record"). I andra har vi inte med detta. Vi har

Läs mer

IBS BI & FS & OP. Bengt Jensfelt Product Manager, PD IBS Kunddag 29 November 2012

IBS BI & FS & OP. Bengt Jensfelt Product Manager, PD IBS Kunddag 29 November 2012 IBS BI & FS & OP Bengt Jensfelt Product Manager, PD IBS Kunddag 29 November 2012 RPM Teknologi och lösningar IBS Statement of Direction RPM är IBS plattform för Business Intelligence-och SOP-lösningar

Läs mer

Microsoft Operations Manager 2005

Microsoft Operations Manager 2005 Microsoft Operations Manager 2005 Grundläggande begrepp Syfte med artikel När jag började arbeta med MOM2K5 upplevde jag det som svårt att få en överblick över alla komponenter och hur dessa hängde ihop.

Läs mer

Det är fullt tillåtet att göra laborationen innan laborationstillfället.

Det är fullt tillåtet att göra laborationen innan laborationstillfället. Observera Det är fullt tillåtet att göra laborationen innan laborationstillfället. Laborationen ska genomföras individuellt, men det är tillåtet att diskutera eventuella problem och lösningar med dina

Läs mer

[HUR DU ANVÄNDER PAPP] Papp är det program som vi nyttjar för att lotta turneringar och se resultat.

[HUR DU ANVÄNDER PAPP] Papp är det program som vi nyttjar för att lotta turneringar och se resultat. PAPP Papp är det program som vi nyttjar för att lotta turneringar och se resultat. Förberedelser inför en turnering. Ladda ner papp för windows, spara zipfilen på lämpligt ställe på din dator och lägg

Läs mer

SAS Institute Education Center. Kurser hösten 2007

SAS Institute Education Center. Kurser hösten 2007 SAS Institute Education Center Kurser hösten 2007 Möt hösten med SAS Institute. Till hösten presenterar vi sex nya kurser på schemat. Det finns nyheter för nästan alla olika jobbprofiler. Vad sägs om SAS

Läs mer

Innehåll Security. Chapter 4 och 7 Beginning SQL Server 2008 for Developers

Innehåll Security. Chapter 4 och 7 Beginning SQL Server 2008 for Developers Innehåll Security SQL Injektions Säkerhetssystemet Schema Login Användare Roller User Applikationsanvändare AppUser Backup av databas Restore / Recovery av databas Flytta/Kopiera en databas, Detach/Attach

Läs mer

Prestanda, skalbarhet och tillgänglighet Torbjörn Stavenek

Prestanda, skalbarhet och tillgänglighet Torbjörn Stavenek Prestanda, skalbarhet och tillgänglighet Torbjörn Stavenek Agenda Teori Funktionell nedbrytning Tillgänglighet Exempel från bwin Om bwin Games Sammanfattning Frågor Teori: CAP CAP Consistency, Availability,

Läs mer

Spara papper! Skriv inte ut sammanfattning utan ladda ner PDF!

Spara papper! Skriv inte ut sammanfattning utan ladda ner PDF! Denna beskrivning har gjorts på Windows 2000 Server (men bör fungera även på Windows XP Home Edition/Professional och Windows 2003 Server). Att installera Oracle 10g kräver ca. 2 GB hårddiskplats och ca.

Läs mer

Från PCAXIS till Statistikatlasen

Från PCAXIS till Statistikatlasen Statistiska centralbyrån Från PCAXIS till Statistikatlasen Ladda statistik i PC-Axisformat Inledning I Statistikatlasen ingår ett litet urval av statistiska variabler ur den stora mängd data som produceras

Läs mer

Data på disk är en teknisk lösning i Capitex Säljstöd som gör att viss information ej sparas i databasen utan direkt på serverns hårddisk.

Data på disk är en teknisk lösning i Capitex Säljstöd som gör att viss information ej sparas i databasen utan direkt på serverns hårddisk. Data på disk Data på disk är en teknisk lösning i Capitex Säljstöd som gör att viss information ej sparas i databasen utan direkt på serverns hårddisk. Lösningen ger förutsättningar för bättre prestanda

Läs mer

X-Route Användarmanual Innehåll

X-Route Användarmanual Innehåll X-Route Användarmanual Innehåll Innehåll och Produktspecifikation... 2 X-Route Elektronisk Körjournal Produktspecifikation... 2 Kom igång med X-Route Elektronisk Körjournal... 3 För in Mjukvarunyckel...

Läs mer

Tentamen i. Databasteknik

Tentamen i. Databasteknik Tentamen i Databasteknik Torsdagen den 10/3 2005 14.00-19.00 Tillåtna hjälpmedel: Allt tänkbart material Använd bara framsidan på varje blad Skriv max en uppgift per blad. Skriv tydligt. Motivera allt.

Läs mer

Uppgraderingsinstruktion för Tekis-FB 7.0.3

Uppgraderingsinstruktion för Tekis-FB 7.0.3 Uppgraderingsinstruktion för Tekis-FB 7.0.3 Allmänt Tekis-FB 7.0.3 innefattar följande komponenter: Tekis-FB Avisering 7.0.3 Officiella vyer och webbtjänster 7.0.3 Tekis-FB Hjälpprogram 7.0.3 Tekis-KID

Läs mer

Tommy Färnqvist, IDA, Linköpings universitet. 1 ADT Map/Dictionary 1 1.1 Definitioner... 1 1.2 Implementation... 2

Tommy Färnqvist, IDA, Linköpings universitet. 1 ADT Map/Dictionary 1 1.1 Definitioner... 1 1.2 Implementation... 2 Föreläsning 4 ADT Map/Dictionary, hashtabeller, skip-listor TDDC91: DALG Utskriftsversion av föreläsning i Datastrukturer och algoritmer 9 september 2015 Tommy Färnqvist, IDA, Linköpings universitet 4.1

Läs mer

SEB. Four foils. SEB IT Lars-Göran Karlsson

SEB. Four foils. SEB IT Lars-Göran Karlsson SEB Four foils SEB IT Lars-Göran Karlsson SEB IT Nu ett IT bolag inom SEB koncernen Tidigare uppdelat på två bolag SEB IT Partner för utveckling SEB IT Service för drift Nu två enheter inom SEB IT SEB

Läs mer

VI SI CLOSETALK AB SYSTEMKRAV

VI SI CLOSETALK AB SYSTEMKRAV 2010-01-18 VI SI CLOSETALK AB SYSTEMKRAV 1 MJUK- OCH HÅRDVARUKRAV I detta dokument beskrivs de minimikrav och rekommendationer för mjukvara samt hårdvara som gäller för VISI System AB:s produkter. Visi

Läs mer

Datatal Flexi Presentity

Datatal Flexi Presentity Datatal Flexi Presentity En snabbguide för Presentity Innehållsförteckning 1. Login 2 2. Hänvisa 3 2.1 Att sätta hänvisningar 3 2.2 Snabbknappar 4 2.3 Windows gadget 4 3. Meddelande 5 4. Status 6 4.1 Exempel

Läs mer

Uppgift 18 Eget programval 2010 02 02

Uppgift 18 Eget programval 2010 02 02 Prezi lathund Vi skall skapa en presentation med hjälp av Prezi. För att använda Prezi behöver man logga in, dvs. skapa ett konto hos Prezi. När man sedan loggat in kan man skapa en ny Prezi. Det första

Läs mer

Manual till DIKO 2012-10-19

Manual till DIKO 2012-10-19 Manual till DIKO 2012-10-19 Innehåll Manual till DIKO 2012-10-19... 1 1 Använda DIKO med en dator... 2 1.1 För att logga in i DIKO... 2 1.2 Dag... 3 1.3 Importera bilder... 4 1.4 Redigera bilder i samband

Läs mer

Databaser Design och programmering Minnesteknik Minnesteknik, forts Utvecklingen Hårddisk Hårddisk, forts

Databaser Design och programmering Minnesteknik Minnesteknik, forts Utvecklingen Hårddisk Hårddisk, forts Databaser Design och programmering Fysisk design av databasen att ta hänsyn till implementationsaspekter minnesteknik filstrukturer indexering 1 Minnesteknik Primärminne (kretsteknik) Flyktigt Snabbt Dyrt

Läs mer

Lathund för Novell Filr

Lathund för Novell Filr 1(57) Stadsledningsförvaltningen IT-avdelningen Lathund för Novell Filr 2(57) Innehåll 1. Introduktion... 4 2. Termer... 4 3. Icke tillåtna tecken i filnamn... 4 4. ipad... 5 4.1 Installation... 5 4.2

Läs mer

E-posthantering med Novell Groupwise WebAccess

E-posthantering med Novell Groupwise WebAccess E-posthantering med Novell Groupwise WebAccess En liten hjälpreda sammanställd av Thomas Granhäll. Materialet får kopieras fritt! 2003 Följande moment behandlas i denna manual: 1. Logga in 2. Ta emot och

Läs mer

Instruktioner för uppdatering från Ethiris 4.10 till 5.x

Instruktioner för uppdatering från Ethiris 4.10 till 5.x Instruktioner för uppdatering från Ethiris 4.10 till 5.x Nedan följer instruktioner för hur man går till väga vid uppdatering av ett Ethirissystem version 4 till version 5. När man uppdaterar Ethiris från

Läs mer

AVCAD 4.0 för Windows

AVCAD 4.0 för Windows BILAGA A Installation och konfigurering av SQL-server. Applikationen kan antingen köras mot MS SQL-server eller MS Access. Koppling mot MS-ACCESS databas. MS Access installeras och konfigureras automatiskt

Läs mer

NYHETER I AUTOCAD 2005

NYHETER I AUTOCAD 2005 NYHETER I AUTOCAD 2005 Nedan följer en kort beskrivning av nyheter och förbättringar i AutoCAD 2005, jämfört med AutoCAD 2004. Nyheterna är inte ordnade i speciell ordning. UTÖKADE HJÄLPFUNKTIONER Rullgardinsmenyn

Läs mer

Innehåll. Dokumentet gäller från och med version 2014.3 1

Innehåll. Dokumentet gäller från och med version 2014.3 1 Innehåll Introduktion... 2 Före installation... 2 Beroenden... 2 Syftet med programmet... 2 Installation av IIS... 2 Windows Server 2008... 2 Windows Server 2012... 6 Installation av webbapplikationen

Läs mer

Minihandbok för skoladministratörer version 1.6

Minihandbok för skoladministratörer version 1.6 UEDB (UNGDOM OCH ELEVDATABASEN) Minihandbok för skoladministratörer version 1.6 Eva Rehnberg 2014-08-18 En utförligare handbok för administratörer finns att tillgå inloggad i UEDB. Den här handboken är

Läs mer

Scala Doc SQL Installation

Scala Doc SQL Installation Scala Doc SQL Installation För uppgradering se nedan: Uppgradering till ScalaDoc På Servern: Börja med att köra programmet D:\Setup.exe (Om D:\ är CDROM enheten) så installeras Scala Doc till ett bibliotek

Läs mer

Anvisningar för projektarbete och dokumentation (v3-v10)

Anvisningar för projektarbete och dokumentation (v3-v10) Anvisningar för projektarbete och dokumentation (v3-v10) Anteckna (för egen del) vilka medlemmar som ingår i din grupp. Se till att samma uppgifter är mejlade till kursansvarig jesper.hakerod@hh.se senast

Läs mer

Listan på egna rapporter inkluderar rapporter från TIDPLAN.MDB

Listan på egna rapporter inkluderar rapporter från TIDPLAN.MDB Vad är nytt i Easy Planning 6.52 Detta är en stor uppdatering som innehåller många förbättringar samt en del nya funktioner. Vi rekommenderar alla våra kunder att uppdatera till denna version. 1. Bokningsvy

Läs mer

Fältnamn /Rubrik Fältnamn /Rubrik Fältnamn /Rubrik Fältnamn /Rubrik Data Data Data Data Data Data Data Data

Fältnamn /Rubrik Fältnamn /Rubrik Fältnamn /Rubrik Fältnamn /Rubrik Data Data Data Data Data Data Data Data Datahantering i Excel Grundbegrepp I alla typer av databaser finns alltid en tabell där informationen i databasen fysiskt finns lagrad. Tabellen har samma enkla uppbyggnad som en tabell i ordbehandlingsprogrammet

Läs mer

Vi visar i denna guide hur man kommer igång med sin nychippade Xbox360. När vi skriver spel i denna guide så menar vi era JTAG/RGH preparerade spel.

Vi visar i denna guide hur man kommer igång med sin nychippade Xbox360. När vi skriver spel i denna guide så menar vi era JTAG/RGH preparerade spel. Grattis till din nychippade Xbox360. Denna guide är framställd av Xboy.se, sprid gärna denna guide, lägg upp på era hemsidor eller bloggar men glöm inte var den kommer ifrån. Var tydliga med att denna

Läs mer

NYHETER I INVENTOR 2012

NYHETER I INVENTOR 2012 NYHETER I INVENTOR 2012 NYHETER I INVENTOR 2012 Här nedan följer en kort beskrivning av de flesta nyheterna och förbättringarna i Autodesk Inventor 2012 jämfört med Autodesk Inventor 2011. AUTODESK INVENTOR

Läs mer

Dokumentmallar i praktiken, Nyps

Dokumentmallar i praktiken, Nyps Dokumentnamn Dokumenttyp Datum Dokumentmallar i praktiken Handledning 2009-08-13 Diarienr/Projektnr Upprättad av Godkänd av Version Magnus Österlund, Daniel Madsén 0.4 Dokumentmallar i praktiken, Nyps

Läs mer

Prestandatest Förberedelser & Faktainsamling. LIGHTS IN LINE AB Tegnérgatan 37 111 61 STOCKHOLM info@lightsinline.se

Prestandatest Förberedelser & Faktainsamling. LIGHTS IN LINE AB Tegnérgatan 37 111 61 STOCKHOLM info@lightsinline.se Prestandatest Förberedelser & Faktainsamling LIGHTS IN LINE AB Tegnérgatan 37 111 61 STOCKHOLM info@lightsinline.se Sida 2 (6) Innehåll 1 Introduktion... 3 2 Sammanfattning... 3 3 Testmetoder... 3 4 Prestandamål

Läs mer

Insamling, lagring och bearbetning av data för beslutsstöd i stora organisationer

Insamling, lagring och bearbetning av data för beslutsstöd i stora organisationer Datavetenskap Eva Pettersson Johan Westerdahl Insamling, lagring och bearbetning av data för beslutsstöd i stora organisationer - En övergripande studie av datalager Examensarbete, C-nivå 2005:06 Insamling,

Läs mer

Vilken version av Dreamweaver använder du?

Vilken version av Dreamweaver använder du? Sida 1 av 7 Lektion 1: sida 1 av 4 Till kursens framsida Sida 2 av 4» Lektion 1 Då ska vi sätta igång med den här kursens första lektion! Här kommer du att få lära dig hur man skapar och förbereder webbplatser

Läs mer

Tentamen 2I1033, IT i Organisationer och Databasteknik lördag 17/4 2004, kl. 10 15 LÖSNINGSFÖRSLAG

Tentamen 2I1033, IT i Organisationer och Databasteknik lördag 17/4 2004, kl. 10 15 LÖSNINGSFÖRSLAG Institutionen för Data- och Systemvetenskap SU/KTH Maria Bergholtz Tentamen 2I033, IT i Organisationer och Databasteknik lördag 7/4 2004, kl. 0 5 LÖSNINGSFÖRSLAG Inga hjälpmedel tillåtna. Skriv bara på

Läs mer

OBS! Det är av största vikt att innan konfiguration av modulen, genomfört de inställningar som presenteras med bilagorna till denna manual.

OBS! Det är av största vikt att innan konfiguration av modulen, genomfört de inställningar som presenteras med bilagorna till denna manual. 1 LB-M-EX 0001 2010 LB-M-EX 0001 2010 Användarmanual för Lockbee Backup Exchange 2007 Användarmanualen är avsedd att ge en närmare introduktion av Lockbee Backup Exchange 2007 och dess funktioner och nyttjande.

Läs mer