Repetisjon av transaksjonshåndtering og samtidighetskontroll. Lana Vu

Like dokumenter
Transaksjonshåndtering og samtidighetskontroll

Transaksjonshåndtering og samtidighetskontroll

ndtering og samtidighetskontroll

Transaksjonshåndtering og samtidighetskontroll

Presentasjon av doktorgradsprosjekt

Transaksjonshåndtering Del 3

Transaksjonshåndtering Del 3

For alle ikke-trivielle FDer X A i R: eller A er et nøkkelattributt i R eller X K for noen kandidatnøkkel K i R

Transaksjonshåndtering Del 3

Repetisjonsforelesning, SQL og utover

Transaksjonshåndtering Del 3

Transaksjonshåndtering Del 3

Transaksjonshåndtering Del 3

Transaksjonshåndtering Del 2

DBS20 - Introduksjon til transaksjonsprosessering og teori

Transaksjonshåndtering Del 2

DBMS Database Management System (repetisjon) Programmeringsgrensesnitt. Serialiserbarhet

DBS21 Samtidighetskontrollteknikker

Deling av data Transaksjoner

Deling av data Transaksjoner

Samtidighetsfenomener og anomalier i eksekveringsplaner (kursorisk) INF3100 Ellen Munthe-Kaas 1

Transaksjonshåndtering Del 2

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

INF3100 Databasesystemer. Transaksjonshåndtering. ndtering Del 3. Ragnar Normann

Transaksjoner. transaksjon. når starter/slutter 1 trans.?

Øving 5: Transaksjonshåndtering, logging og normalisering

Transaksjoner og flerbrukerproblematikk. Transaksjoner

Isolasjon i postgres og mysql

INF1300 Introduksjon til databaser

Oppgaver INF3100. Oversikt over innholdet

UNIVERSITETET I OSLO Institutt for informatikk. En teoretisk studie av Snapshot Isolation. Masteroppgave 60 studiepoeng. Lene T.

Replikeringsgrafer og multiversjonsserialiserbarhet. Jon Grov. Hovedfagsoppgave. 29. april 2003

Samtidighetsfenomener og anomalier i eksekveringsplaner. INF Ellen Munthe-Kaas 1

INF3100 V2018 Obligatorisk oppgave nr. 2

INF1300 Introduksjon til databaser

Innhold. Introduksjon til parallelle datamaskiner. Ulike typer parallelle arkitekturer. Prinsipper for synkronisering av felles hukommelse

Hva har vi gjort? SQL og Databasedesign

UNIVERSITETET I OSLO

INF1300 Introduksjon til databaser

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

UNIVERSITETET I OSLO

Andre sett obligatoriske oppgaver i INF3100 V2010

Normalisering. ER-modell

Transaksjoner og flerbrukerproblematikk. Transaksjoner

Andre sett obligatoriske oppgaver i INF3100 V2013

UNIVERSITETET I OSLO

Forord. Faglig ansvarlig og hovedveileder for oppgaven har vært professor Mads Nygård. Medveileder har vært doktoringeniør stipendiat Hien Nam Le.

INF5030. Håndtering av virksomhetskritiske data

Masteroppgave 60 studiepoeng

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det.

Det matematisk-naturvitenskapelige fakultet. Kontroller at oppgavesettet er komplett før du begynner å besvare det

Andre sett obligatoriske oppgaver i INF3100 V2008

Systemfeil og logging

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Systemaspekter ved SQL

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Oppgave 1 Datamodellering 25 %

Andre sett obligatoriske oppgaver i INF3100 V2009

Minikompendium TDT4145 databasemod og dbsys

Transaksjonsmodell. Samtidighet (1) ACID-transaksjoner. Samtidighet (2) Systemkræsj (1) Kapittel 17, Coping With System Failure

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Andre sett obligatoriske oppgaver i INF3100 V2012

Databasemodellering og DBMS. Oppsummering

Forelesning 28. Grafer og trær, eksempler. Dag Normann - 5. mai Grafer og trær. Grafer og trær. Grafer og trær

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

DBS22 Databasegjenopprettingsteknikker

Parallelle og distribuerte databaser del I

Andre sett obligatoriske oppgaver iinf3100v2011

Systemaspekter ved SQL

Systemfeil og logging

Eksamensoppgåve i TDT4145 Datamodellering og databasesystem

Løsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Fakultet for informasjonsteknologi, Løsning på kontinuasjonseksamen i TDT4190 / SIF8042 Distribuerte systemer August 2005,

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Fakultet for informasjonsteknologi, Løsning på eksamen i TDT4190 Distribuerte systemer Torsdag 9. juni 2005,

Eksamensoppgåve i TDT4145 Datamodellering og databasesystemer

Eksamensoppgåve i TDT4145 Datamodellering og databasesystemer

UNIVERSITETET I OSLO

Plan. Oppgaver og repetisjon Eksempler med fikspunkt og induksjon: 1. sortering 2. divisjon 3. Heis? IN 315: Foilsett 9: Unity: Arkitekturer

Eksamen i fag SIF8010 Algoritmer og Datastrukturer Tirsdag 14. Desember 1999, kl

Forelesning 33. Repetisjon. Dag Normann mai Innledning. Kapittel 11

MAT1030 Diskret matematikk

Innledning. MAT1030 Diskret matematikk. Kapittel 11. Kapittel 11. Forelesning 33: Repetisjon

Andre sett obligatoriske oppgaver i INF3100/INF4100 V2007

Avsluttende eksamen i TDT4120 Algoritmer og datastrukturer

Dagens temaer. Kort repetisjon. Mer om cache (1) Mer om cache (2) Read hit. Read miss. Write hit. Hurtig minne. Cache

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO

Concurrency. Lars Vidar Magnusson. September 20, Lars Vidar Magnusson () Forelesning i Operativsystemer September 20, / 17

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Fakultet for informasjonsteknologi, Oppgave 1 Flervalgsspørsmål ( multiple choice ) 15 %

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Statisk semantisk analyse - Kap. 6

4/5 store parallelle maskiner /4 felles hukommelse in 147, våren 1999 parallelle datamaskiner 1. når tema pensum.

INF3140 Modeller for parallellitet INF3140/4140: Låser og Barrierer

Transkript:

Repetisjon av transaksjonshåndtering og samtidighetskontroll Lana Vu anhlv@ifi.uio.no

Repetisjon ACID- egenskapene Transaksjon Eksekveringsplan og serialiserbarhet Konfliktserialiserbarhet og presedensgraf 2- faselåsing (2 Phase Locking) Isolasjonsnivåer Snapshot isplation First Updater Wins (FUW)

ACID Atomicity - Alt eller ingenting. Hele transaksjonen feiler dersom en liten del av den feiler Consitency - Alle «krav/constraints» i databasen er oppfylt. Isolation - Transaksjoner skal ikke merke at andre transaksjoner utføres samtidig med dem selv Durability - Når transaksjoner er avsluttet, skal effekten av dem være varig og ikke kunne påvirkes av systemfeil

Transaksjon En transaksjon er en sekvens av operasjoner som bevarer konsistens i databasen Eksempler: - Bankoverføringer - Reservasjonssystemer - Kioskautomaten i 3. etasje

Eksekveringsplan En eksekveringsplan (schedule) S for en mengde transaksjoner {T1,,Tn} er en fletting av operasjonene i T1,,Tn. Hva er en «god» eksekveringsplan? - En som garanterer serialiserbarhet

Serialiserbarhet En eksekvering av en mengde transaksjoner er seriell hvis eksekveringen fullføres fullstendig for én transaksjon før neste transaksjon eksekveres. Eksekveringen er serialiserbar hvis transaksjonseksekveringene er slik at det fins en seriell eksekvering som gir samme totalresultat

Konfliktserialiserbarhet To eksekveringsplaner S1 og S2 kalles konfliktekvivalente hvis S1 kan omformes til S2 ved en serie ombyttinger av nabooperasjoner som ikke er i konflikt med hverandre En eksekveringsplan er konfliktserialiserbar hvis den er konfliktekvivalent med en seriell eksekveringsplan

Eksempel fra Ellen SC kan omformes til en seriell eksekveringsplan Altså er SC konfliktserialiserbar.

Presedensgraf Kan finne ut om en eksekveringsplan er konfliktserialiserbar ved hjelp av en presedensgraf. La S være en eksekveringsplan, og la pi(a) og qk(b) være to (vilkårlige) operasjoner i S. Notasjonen pi(a) <S qk(b) betyr at pi(a) gjøres før (kommer foran) qk(b) i S. Hvordan sette opp presedensgrafen til en eksekveringsplan S: 1. Noder: Transaksjonene i S 2. Kanter: Ti Tk (der ) dersom - pi(a) <S qk(a) og - minst en av pi og qk er en skriveoperasjon

Eksempel Sykelfri graf indikerer konfliktserialiserbarhet Tegn P(S1) for S1 = r1(a); r2(a); r3(b); w1(a); r2(c); r2(b); w2(b);w1(c); Tegn P(S2) for S2 = w3(a); r1(a); w1(b); r2(b); w2(c); r3(c)

2- faselåsing Kan ha shared locks og exclusive locks Hvordan sikre serialiserbarhet? Låser alene sikrer ikke dette. 2PL er en låseprotokoll som garanterer serialiserbarhet. Viktig regel En transaksjon som har utført en unlock- operasjon, har ikke lov til å utføre flere lock- operasjoner.

Eksempel Sett låser etter 2PL på S: S = r1(a); r2(a); r3(b); w1(a); r2(c); r2(b); w2(b);w1(c); S = sl1(a); r1(a); sl2(a); r2(a); sl3(b); r3(b); u3(b); xl1(a); w1(a); sl2(c); r2(c); sl2(b); r2(b); xl2(b); w2(b); u2(a); u2(b); u2(c); xl1(c); w1(c); u1(a); u1(c);

Isolasjonsnivåer Hvor isolert en transaksjon skal være fra andre transaksjoners endringer. Full isolasjon: Seriell eksekveringsplan. Høy isolasjon: Lav samtidighet og mye «overhead». Lav isolasjon: Høy samtidighet, men det kan oppstå flere samtidighetsfenomener og anomalier. Vanlig å senke isolasjonsnivået for bedre ytelse. F.eks tillate dirty reads, fantomlesing osv. som kan føre til feil

Snapshot isolation Ofte brukt pga. bedre ytelse enn serialiserbarhet. I SI vil en transaksjon T i hele sin levetid lese de committede verdiene databasen hadde ved TS(T) (starttiden til transaksjon T). T blir altså ikke påvirket av skriveoperasjoner som andre transaksjoner gjør etter TS(T). SI sikrer ikke serialiserbarhet! Men SI gir høy grad av fletting og er standardstrategien for samtidighetskontroll i de fleste av dagens kommersielle DBMSer.

First Updater Wins (SI- protokoll) Se Ellen sine slides for protokoll Eksempel: Se eksamen 2013